Description of problem: During a schema reload operation the search of an existing entry may randomly report no results.
Steps to Reproduce: 1. issue a schema reload 2. run a query (ldapsearch) that is expected to return a single entry
Actual results: Sometimes the result set is empty, e.g.:
search: 2 result: 0 Success
Expected results:
The result set should always be non-empty
attachment 0001-Ticket-47973-During-schema-reload-sometimes-the-sear.patch
May I ask why these lines were removed? It adds back an internal pseudo attribute... {{{ 189 189 slapi_log_error(SLAPI_LOG_FATAL, "schemareload", "Schema reload task finished.\n"); 190 191 slapi_log_error(SLAPI_LOG_FATAL, "schemareload", 192 "Register internal schema.\n"); 193 rv = slapi_reload_internal_attr_syntax(); 194 slapi_log_error(SLAPI_LOG_FATAL, "schemareload", 195 "Register internal schema finished.\n"); 196 197 190 } else { }}}
Replying to [comment:3 nhosoi]:
May I ask why these lines were removed? It adds back an internal pseudo attribute...
Sure. I moved slapi_reload_internal_attr_syntax() into slapi_reload_schema_files() - made more sense to do it there, but it wasn't necessary.
{{{ 189 189 slapi_log_error(SLAPI_LOG_FATAL, "schemareload", "Schema reload task finished.\n"); 190 191 slapi_log_error(SLAPI_LOG_FATAL, "schemareload", 192 "Register internal schema.\n"); 193 rv = slapi_reload_internal_attr_syntax(); 194 slapi_log_error(SLAPI_LOG_FATAL, "schemareload", 195 "Register internal schema finished.\n"); 196 197 190 } else { }}}
Ah, you are right. Thanks!
42e2df3..e0c78e1 master -> master commit e0c78e1 Author: Mark Reynolds mreynolds@redhat.com Date: Thu Jan 8 15:43:43 2015 -0500
6229ad9..2da0bd6 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 2da0bd6
6ad2397..143550a 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 143550a
The patch did not apply cleanly to 1.3.1. There is a memory leak that needs to be addressed before it can be pushed to 1.3.1 & 1.2.11
The memory leak existed before my patch was applied. Processing with existing commits and will open a new ticket for the memory leaks
b0cf445..3fafcbe 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 3fafcbe0a2ada038f02efdfdce77c1768f0e1819
8e79bef..457252f 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 457252f
Reopening to investigate https://bugzilla.redhat.com/show_bug.cgi?id=1413692.
Note: 1.2.11 may need to have a bug, as well.
git patch file (master) 0001-Ticket-47973-custom-schema-is-registered-in-small-ca.patch
git patch file (master) -- CI test; adding test_ticket47973_case 0002-Ticket-47973-CI-Test-case-test_ticket47973_case.patch
Hi Noriko,
I agree that this fix prevents the normalization that lowercase the attribute names. From a debug session, it lowercase the attribute name because it does not find in name2asi the attribute syntax. The attribute syntax is present in name2asi_tmp but I failed to find a patch that would use name2asi_tmp during a reload.
I do not really understand the benefit of normalizing attribute name so I think it is fine to skip this step during schema reload. Would it be possible to skip it also during schema load (at regular startup).
Replying to [comment:11 tbordaz]:
Hi Noriko, I agree that this fix prevents the normalization that lowercase the attribute names. From a debug session, it lowercase the attribute name because it does not find in name2asi the attribute syntax. The attribute syntax is present in name2asi_tmp but I failed to find a patch that would use name2asi_tmp during a reload. I do not really understand the benefit of normalizing attribute name so I think it is fine to skip this step during schema reload. Would it be possible to skip it also during schema load (at regular startup).
Thanks for your comments, Thierry. Actually, I share the same question. Probably, there was a reason why the string was "normalized" by lowering the case, e.g., to avoid strcasecmp for the performance reason(?) in the beginning? Definitely, we should come back this later, but I'm reluctant to change it now. We also have another schema reload bug revealed by the test case 0002-Ticket-47973-CI-Test-case-test_ticket47973_case.patch​ :(
I'm opening 2 bugs for the issues. And let's separate it from this ticket. Thanks!!
That is fine for me. Recording that concern in the ticket is far enough.
Thanks for the patch. ACK
FYI,
I'm opening 2 bugs for the issues. And let's separate it from this ticket.
https://fedorahosted.org/389/ticket/49092 schema reload task picks up schema when the validation fails.
https://fedorahosted.org/389/ticket/49093 Need investigation on the necessity of normalize_oc* calls in schema.c
Thanks for the review and the discussion, Thierry!
Pushed to master: 9b702ed..75a1958 master -> master commit a0545ed commit 75a1958
Pushed to 389-ds-base-1.3.5 branch: 0cb9c6c..28309c3 389-ds-base-1.3.5 -> 389-ds-base-1.3.5 commit 28309c3
Pushed to 389-ds-base-1.2.11 branch: a87ddab..90702d1 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 90702d1
Metadata Update from @tbordaz: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.33
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/1304
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)
Log in to comment on this ticket.