On 08/04/2013 09:06 PM, Stefan Seelmann wrote: > On 08/04/2013 11:21 AM, Stefan Seelmann wrote: >> On 08/04/2013 11:05 AM, Emmanuel Lécharny wrote: >>> Le 8/4/13 10:02 AM, Stefan Seelmann a écrit : >>>> Seems this changes breaks a test in core-integ: >>>> org.apache.directory.server.core.operations.search.SearchIT.testSearchEmptyDNWithSubLevelScope() >>>> >>>> With this change the sublevel scope search beginning at root only >>>> returns entries from ou=system, but not from ou=schema. >>> >>> Ahha... This is strange because the test is passing for me. >>> >>> What kind of error do you get ? >>> >> >> java.lang.AssertionError >> at org.junit.Assert.fail(Assert.java:86) >> at org.junit.Assert.assertTrue(Assert.java:41) >> at org.junit.Assert.assertTrue(Assert.java:52) >> at >> org.apache.directory.server.core.operations.search.SearchIT.testSearchEmptyDNWithSubLevelScope(SearchIT.java:1774) >> >> Same on Jenkins: >> https://builds.apache.org/view/A-D/view/Directory/job/dir-apacheds-jdk16-ubuntu-deploy/1070/ >> >> Maybe it only fails with JDBM backend (I assume you are using mavibot)? >> > > I also tested with mavibot, same error :( >
I found the issue, as often with random failures ordering of HashMap/HashSet is the cause... For the record: the test starts searching at RootDSE with filter (objectClass=organizationalUnit) and subtree scope. As the test starts search at RootDSE and we have two partitions (ou=system and ou=schema) we do two searches, one for each parttion, this is done in DefaultPartitonNexus.searchFromRoot(), line 778. The "partitions" variable is a HashMap, in my case the first partition that is searched is "ou=system". There are only 15 candidates that match the filter, so the DefaultOptimzer annotates the filter (EqualityNode) and sets the 15 candidates. So far so good. Now the search for the second partition is done. It uses the same filter, which is already annotated from the previous search! This partition has more than 100 candidates which matches the filter, so the DefaultOptimizer stops fetching candidates, but the "candidates" annotation from the previous search remains! So a simple fix is to set the "candidates" annotation to null (done in r1510343). However I wonder if the reuse of the mutalble/annotatable filter for RootDSE based search may have other side effects? I think at the beginning of a search we should reset the annotation map, however I didn't find the right place where to do it. Any ideas? Kind Regards, Stefan
