directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-1258) memory leak (outstanding requests) in SearchHandler
Date Wed, 17 Sep 2008 14:15:44 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631783#action_12631783
] 

Emmanuel Lecharny commented on DIRSERVER-1258:
----------------------------------------------

About your point #2 : The rootDSE search request is atomic, and there is no need to store
it in the outstandingRequest session object, as it won't be abandonned (IFAIR, the outsandingRequest
attribute is used for abandonned/TimedOut/SizedOut requests)

> memory leak (outstanding requests) in SearchHandler 
> ----------------------------------------------------
>
>                 Key: DIRSERVER-1258
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1258
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.5.4
>            Reporter: Norval Hope
>             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.


Mime
View raw message