ExceptionInterceptor and undue lookup

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

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...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: ExceptionInterceptor and undue lookup

[Alex Karasulu <ak...@apache.org>]

On Thu, Jan 6, 2011 at 7:35 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

> Hi,
>
> 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.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Re: ExceptionInterceptor and undue lookup

[Stefan Seelmann <se...@apache.org>]

On Thu, Jan 6, 2011 at 10:21 PM, Stefan Seelmann <se...@apache.org> wrote:
> On Thu, Jan 6, 2011 at 6:35 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>> Hi,
>>
>> 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.
>
> Can't that be handled at other places?
>
> The DefaultPartitionNexus.getPartition(DN) seems to handle the case
> that no partition for the base DN exists and throws an
> LdapNoSuchObjectException. (example: base DN is
> ou=people,dc=example,dc=com but not partiton for dc=example,dc=com
> exists)
>
> In the other case, when an partition exists then the problem is in
> DefaultSearchEngine.cursor() method. This method returns an
> EmptyIndexCursor if the base doesn't exist, IMO that should throw the
> exception.

I created a Jira and attached a patch:
  https://issues.apache.org/jira/browse/DIRSERVER-1594

Kind Regards,
Stefan

Re: ExceptionInterceptor and undue lookup

[Stefan Seelmann <se...@apache.org>]

On Thu, Jan 6, 2011 at 6:35 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> 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.

Can't that be handled at other places?

The DefaultPartitionNexus.getPartition(DN) seems to handle the case
that no partition for the base DN exists and throws an
LdapNoSuchObjectException. (example: base DN is
ou=people,dc=example,dc=com but not partiton for dc=example,dc=com
exists)

In the other case, when an partition exists then the problem is in
DefaultSearchEngine.cursor() method. This method returns an
EmptyIndexCursor if the base doesn't exist, IMO that should throw the
exception.

Kind Regards,
Stefan