On Thu, Jan 6, 2011 at 7:35 PM, Emmanuel Lecharny <email@example.com>
following my previous mail, I have a bit more insight about the problem.
When we do a search, we not only give a base DN, but also a filter and a scope. Now, there are a few possibilities :
1) We have entries under the base DN, accepted by the filter and the scope
2) We have entries under the base DN, but the filter and the scope discard all of them, thus returning no entries
3) The base DN is not a DN in the DIT, the filter and scope are not even used, thus generating a NO_SUCH_OBJECT result.
The ExceptionInterceptor extra lookup is just checking the third case. We can't handle this case in the SearchHandler, because the candidate have potentially been ruled out by the filter and the scope, and we can't anymore make a distinction between case #2 and case #3.
That left us with the second option : modifying the cursor implementation so that we now if there are some candidates (and we must leverage the DN index for that. It probably requires some complex modification in the Cursor API and the backend, some parts I'm not familiar with.
I'm going to create a JIRA with those informations, and we will try to fix that later. It's not urgent...
Yeah if it's a performance issue then we can tackle it after we get 2.0.0-M1 out the door.