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