#47973 During schema reload sometimes the search returns no results
Closed: wontfix None Opened 7 years ago by nhosoi.

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.:

extended LDIF

LDAPv3

base <ou=People,dc=redhat,dc=local> with scope subtree

filter: (uid=test799)

requesting: ALL

search result

search: 2
result: 0 Success

numResponses: 1

Expected results:

The result set should always be non-empty


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) -- 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

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

a year ago

Login to comment on this ticket.

Metadata