directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope (JIRA)" <>
Subject [jira] Closed: (DIRSERVER-1258) memory leak (outstanding requests) in SearchHandler
Date Sat, 20 Sep 2008 23:01:44 GMT


Norval Hope closed DIRSERVER-1258.

Thanks Emmanuel. Have verified the modified patch on Windoze.

> memory leak (outstanding requests) in SearchHandler 
> ----------------------------------------------------
>                 Key: DIRSERVER-1258
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.5.4
>            Reporter: Norval Hope
>            Assignee: Emmanuel Lecharny
>             Fix For: 1.5.5
>         Attachments: DIRSERVER-1258-search-handler.patch
> I think there is a memory leak in 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
>  2. When it delegates to handleRootDseSearch() i don't see a
> corresponding session.unregisterOutstandingRequest( req ) call, isn't
> one required?
>  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?)
>  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? (they are unfortunately not uncommon
in the VD usecases I deal with, due to custom partitions written by 3rd parties)
>  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.
>   6. I had a look in the debugger and I think I am seeing evidence of a leak (LdapSession.outstandingRequests.size()
doesn't return to 0 after a single search is submitted by a single client, which my expectation
is that it should)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message