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