Hello
I have a problem with ldapsearch sometimes returning partial results. The result code is still 0 (success), but the list of object is limited to 63 or 127 (it seems there is a 2^n-1 pattern) items instead of expected 136. It will happen after 10 to 15 requests that return the complete result.
The filter is below. It can happen even if only DN are requested (no attributes): (&(|(ou=example1)(ou=example2))(objectClass=netExamplePerson) (!(netExampleHidden=TRUE))(netExempleActive=TRUE))
This is OpenLDAP 2.4.40, BDB 4.8.30. All attributes in the filter are indexed, and it happens after the openldap-data directory has been cleared and everything has been reconstructed from scratch.
On Wed, Feb 25, 2015 at 03:10:41PM +0000, Emmanuel Dreyfus wrote:
I have a problem with ldapsearch sometimes returning partial results. The result code is still 0 (success), but the list of object is limited to 63 or 127
Erratum: previous OpenLDAP release returned 0 (success) when the result is truncated, but 2.4.40 returns an error: search: 2 result: 51 Server is busy
The server log reports the error but does not give a hint about the cause: conn=1000 op=1 SEARCH RESULT tag=101 err=51 nentries=63 text=
Emmanuel Dreyfus wrote:
On Wed, Feb 25, 2015 at 03:10:41PM +0000, Emmanuel Dreyfus wrote:
I have a problem with ldapsearch sometimes returning partial results. The result code is still 0 (success), but the list of object is limited to 63 or 127
Erratum: previous OpenLDAP release returned 0 (success) when the result is truncated, but 2.4.40 returns an error:
git shows that back-bdb didn't change between 2.4.39 and 2.4.40. The only relevant change was actually in .39. ITS#7761.
search: 2 result: 51 Server is busy
The server log reports the error but does not give a hint about the cause: conn=1000 op=1 SEARCH RESULT tag=101 err=51 nentries=63 text=
Howard Chu hyc@symas.com wrote:
git shows that back-bdb didn't change between 2.4.39 and 2.4.40. The only relevant change was actually in .39. ITS#7761.
I had the truncated result with return code 0 on 2.4.33
On Wed, Feb 25, 2015 at 07:16:57PM +0000, Howard Chu wrote:
git shows that back-bdb didn't change between 2.4.39 and 2.4.40. The only relevant change was actually in .39. ITS#7761.
I added some abort() in the code to check where this LDAP_BUSY was coming from and it is indeed in back-bdb/search.c where ITS#7761 patch added the LDAP_BUSY case.
What confuses me is that I do not touch the config. Could it be caused by schema replication? I have tjings like this in the logs: syncrepl_entry: rid=017 be_add cn={12}supann2009,cn=schema,cn=config failed (53) But it does not appear at the time LDPA_BUSY is raised.
On Thu, Feb 26, 2015 at 10:20:47AM +0000, Emmanuel Dreyfus wrote:
What confuses me is that I do not touch the config. Could it be caused by schema replication?
Indeed: removing synrepl for database config causes the problem to vanish.
Perhaps there could be a better way to handle that? I guess I would prefer a longer wait or a hard failure instead of a partial result: I have to redo the search operation anyway.
--On Thursday, February 26, 2015 10:46 AM +0000 Emmanuel Dreyfus manu@netbsd.org wrote:
On Thu, Feb 26, 2015 at 10:20:47AM +0000, Emmanuel Dreyfus wrote:
What confuses me is that I do not touch the config. Could it be caused by schema replication?
Indeed: removing synrepl for database config causes the problem to vanish.
Perhaps there could be a better way to handle that? I guess I would prefer a longer wait or a hard failure instead of a partial result: I have to redo the search operation anyway.
File an ITS?
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, February 26, 2015 10:46 AM +0000 Emmanuel Dreyfus manu@netbsd.org wrote:
On Thu, Feb 26, 2015 at 10:20:47AM +0000, Emmanuel Dreyfus wrote:
What confuses me is that I do not touch the config. Could it be caused by schema replication?
Indeed: removing synrepl for database config causes the problem to vanish.
Perhaps there could be a better way to handle that? I guess I would prefer a longer wait
Wait time has nothing to do with it. Once a config change is received all in-flight operations stop because we can't know whether or not their underlying DB is still valid.
or a hard failure instead of a partial result:
Not possible, that requires knowing before we start processing a search request that a config change is going to happen.
I have to redo the search operation anyway.
Any LDAP client must be prepared to handle this result code anyway, regardless of the circumstances that caused them.
File an ITS?
No, it would simply be closed WONTFIX.
Howard Chu hyc@symas.com wrote:
File an ITS?
No, it would simply be closed WONTFIX.
Right,I will give up syncrepl for schemas, but that tradeoff should be documented, IMO.
openldap-technical@openldap.org
-
Emmanuel Dreyfus -
Howard Chu -
manu＠netbsd.org
-
Quanah Gibson-Mount