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