Good catch Stefan ! I could have spent hours before catchibg thz bug ! Le 4 août 2013 22:51, "Stefan Seelmann" <[email protected]> a écrit :
> 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 > >
