[ http://issues.apache.org/jira/browse/DIRSERVER-644?page=comments#action_12416101 ]
Alex Karasulu commented on DIRSERVER-644: ----------------------------------------- Man I was totally wrong about this. We do not remove outstanding requests at the end of a search. What we need to do is make the SearchResponseIterator remove the outstanding request from the session when it sends a response done result. > Memory Leak in Persistent search ? > ---------------------------------- > > Key: DIRSERVER-644 > URL: http://issues.apache.org/jira/browse/DIRSERVER-644 > Project: Directory ApacheDS > Type: Bug > Components: core > Versions: 1.0-RC3 > Reporter: Emmanuel Lecharny > Assignee: Alex Karasulu > Priority: Blocker > Fix For: 1.0-RC4 > Attachments: SearchTest.java > > After having profiled memory, it seems we have a memory leak in > SessionRegistry. > A little test (attached) does a search N times for N threads, and for each > search, a OutstandingRequest is attached to the session. After a few > thousands of search we fall in OOM. I've put some trace in those methods : > SessionRegistry.addOutstandingRequest > and > SessionRegistry.removeOutstandingRequest > Session Released > addOutstandingRequest 2 > addOutstandingRequest 3 > addOutstandingRequest 4 > ... ( 100 requests) > addOutstandingRequest 99 > addOutstandingRequest 100 > addOutstandingRequest 101 > remove session > The SessionRegistry.removeOutstandingRequest is never called, except if an > exception is raised (NamingException). > It may be on purpose ( persistent search), but we can't assume the server > will be able to hold as many OutstandingRequest as we have search requests - > or entries -. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
