[
https://issues.apache.org/jira/browse/DIRSERVER-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-933.
-----------------------------------------
Resolution: Fixed
Thanks Martin !!!
You have pretty sharp eyes :) I have totally missed this potential overflow. It
has been fixed in http://svn.apache.org/viewvc?view=rev&rev=539036
I'm really impressed by the fact you went so deep into the server and found
this nasty bug ;)
I mark this bug a resolved, as it seems that the previous fix solved your
performance pb, just repopen it if it's not teh case.
Thanks !
> Slow searches using a non-indexed attribute in a filter
> -------------------------------------------------------
>
> Key: DIRSERVER-933
> URL: https://issues.apache.org/jira/browse/DIRSERVER-933
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.5.0
> Reporter: Martin Alderson
> Priority: Critical
> Fix For: 1.5.1
>
>
> When searching for entries in a specific container with a filter such as
> (cn=*) and the cn attribute is not indexed, the server has to test each entry
> in the partition even when the search has been restricted to a container.
> As an example of how bad this could be - if a partition contains millions of
> entries and the user does a search in that partition within a container that
> only contains 1 of those entries, every entry in the partition is checked in
> turn even though the server knows there is only one entry within the
> specified container.
> This is due to the search optimizer which annotates each part of the filter
> with the number of entries that match where it can. For those it can't (such
> as with attributes that are not indexed) this 'count' will default to
> Long.MAX_VALUE - to indicate that it is the worst case. (See
> org.apache.directory.server.core.partition.impl.btree.DefaultOptimizer).
> When these count annotations are checked to decide which part of the filter
> to use first they are dropped down to integers which means the items with the
> worst case value of Long.MAX_VALUE become -1 -- effectively making them the
> best case. (See
> org.apache.directory.server.core.partition.impl.btree.ExpressionEnumerator.enumConj).
> Disclaimer: I have not done any performance testing on this. I just noticed
> the problem while stepping through the code with a debugger.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
