directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: svn commit: r1509945 - /directory/apacheds/trunk/xdbm-partition/src/main/java/org/apache/directory/server/xdbm/search/impl/DefaultOptimizer.java
Date Mon, 05 Aug 2013 08:09:27 GMT
Good catch Stefan ! I could have spent hours before catchibg thz bug !
Le 4 août 2013 22:51, "Stefan Seelmann" <mail@stefan-seelmann.de> 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
>
>

Mime
View raw message