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 16:15:44 GMT

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

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

I was dead wrong on #3 : we need to keep the request in the session, until it dies.

So the proposed patch is not good. We have to add a 'finally' statement, that's granted, but
we some few controls. The request should be removed if :
- it was not a persistent search
or
- it was a persistent search AND we've got an exception.

Now, we also have to remove the request from the session if the persistent search is stopped.

> 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