I have run into this problem today during syncrepl testing, so changed "Ticket origin" to IPA.
I was unable to reproduce the problem (kind of hang of the task). Using a test case (lib389), it succeeds to index an attribute (here 'cn'). For example:
{{{ dn: cn=db2index_2014_2_7_17_55_14,cn=index,cn=tasks,cn=config objectClass: top objectClass: extensibleObject cn: db2index_2014_2_7_17_55_14 nsinstance: changelog nsindexattribute: cn nstaskcurrentitem: 0 nstasktotalitems: 1 nstasklog:: Y2hhbmdlbG9nOiBJbmRleGluZyBhdHRyaWJ1dGU6IGNuCmNoYW5nZWxvZzogRmluaX NoZWQgaW5kZXhpbmcu nstaskstatus: changelog: Finished indexing. nstaskexitcode: 0 }}}
The problem is possibly not systematic or has been fixed since it was reported. I will continue investigation
attachment ticket47619_test.py
I am still failing to reproduce with the attached test case. The test case does the following: - create 1Master-1Consumer - On master enable: referential integrity, memberof, retro-changelog - Create entries on the replicated suffix - Creates several indexes on the 'cn=changelog' suffix and reindex them with tasks.
All reindex completed successfully, although the index are empty. I fail to reproduce on master, 1.3.1, 1.2.11
Interesting. I don't have the original VM anymore so I will close the ticket.
Thank you for your time!
If the server is not restarted is the index really active, does indexing work and try to acquire the lock ?
Regarding the test case: After enabling the RetroCL plugin, at restart, the backend is not found. So it is not locked (in read), just created. Later restart, will find the backend, that is this time acquired in Read and could trigger this hang.
Regarding the index: I need to check. Indexes are created/used with a restart between 'index' configuratin and reindex. I will check without restart
Regarding index:
Once retroCL is enabled and the server restarted. Indexes are really active as soon as the index entry is created and reindex task complete. It does not require a restart to make active the new indexes
attachment 0001-Ticket-47619-test-case.patch
attachment 0002-Ticket-47619-cannot-reindex-retrochangelog.patch
git merge ticket47619
Updating 5b8dfcd..8087f05 Fast-forward dirsrvtests/tickets/ticket47619_test.py | 299 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ldap/servers/plugins/retrocl/retrocl.c | 3 + 2 files changed, 302 insertions(+) create mode 100644 dirsrvtests/tickets/ticket47619_test.py
git push origin master
Counting objects: 18, done. Delta compression using up to 4 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 4.09 KiB, done. Total 10 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 5b8dfcd..8087f05 master -> master
commit 8087f05 Author: Thierry bordaz (tbordaz) tbordaz@redhat.com Date: Wed Jan 15 09:59:13 2014 +0100
Pushed to 389-ds-base-1.2.11:
9034668..a5499cb 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit a5499cb
Metadata Update from @tbordaz: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.3 - 1/14 (January)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/956
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.