directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <nrh...@gmail.com>
Subject Re: Problem in SearchHandler in AD 1.5.4 ?
Date Wed, 15 Oct 2008 02:40:09 GMT
Thanks for the confirmation Alex. FYI Emmanuel had already worked with
me to fix the issue a while ago.

On Tue, Oct 14, 2008 at 10:17 AM, Alex Karasulu <akarasulu@apache.org> wrote:
>
>
> On Wed, Sep 17, 2008 at 3:01 AM, Norval Hope <nrhope@gmail.com> wrote:
>>
>> Hi All,
>>
>> Just had a question about SearchHandler as I'm reviewing to see if
>> some memory leaks I experienced in the old <1.5.0 release code base
>> have been resolved. As best I can tell (apologies if I'm missing
>> something) there seem to be some different probs in the new
>> implementation regarding calling of
>> session.unregisterOutstandingRequest( req ) (the old impl had some
>> probs in the similar but now defunct use of SessionRegistry):
>>  1. Note that SearchHandler.handleIgnoringReferrals() always calls
>> session.registerOutstandingRequest( req ) immediately on entry
>
> Yes this should happen.
>
>>
>>  2. When it delegates to handleRootDseSearch() i don't see a
>> corresponding session.unregisterOutstandingRequest( req ) call, isn't
>> one required?
>
> Yes you are right it should be required.  This is a bug which will cause a
> leak.
>
>>
>>  3. I'm not sure what the right behaviour is for
>> handlePersistentSearch(), but I'd expect that logically
>> session.unregisterOutstandingRequest( req ) would need to be called
>> too (or in this case is the req considered to be outstanding
>> indefinitely?)
>
> Right it need not be called in the case of psearch.  Here the only thing
> that will stop it is an abandon or the destruction of the
> connection/session.
>
>>
>>  4. In the other normal search cases, shouldn't
>> session.unregisterOutstandingRequest( req ) be in a finally block so
>> it is also called when exceptions are encountered?
>
> Yes indeed you are right again.  Another lousy leak.
>
>>
>>  5. The old impl had a memory leak for searches when no results were
>> returned, as best I can tell the new cursor stuff doesn't suffer the
>> same problem but just wanted to throw this boundary case out there for
>> special consideration.
>
> Best thing to do is write some test cases and see if we can produce a leak
> for this boundary case.  Should be pretty easily done.
>
> FYI once we move to MINA 2.0 we can start looking at the slow client problem
> as well as hunting down more leaks in preparation for ADS 2.0.
>
> Thanks,
> Alex
>
>

Mime
View raw message