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