[
https://issues.apache.org/jira/browse/DIRSERVER-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722602#action_12722602
]
Simon Temple commented on DIRSERVER-644:
----------------------------------------
I think the original patch has made it through although it's now in different
classes due to refactoring.
However, I think there is a leak if a search is valid but unsuccessful. I.e.
If the search returns an empty enumeration the server side registry continues
to hold a reference to the search session.
Here's an example client snippet I used to re-create the problem:
<snip>
Attributes matchAttrs = new BasicAttributes( "objectClass", "typeinfo",
true );
NamingEnumeration<SearchResult> en = null;
en = ctx.search( name, matchAttrs, new String[] { "networkid" } );
en.close( );
<snip>
My proposed fix to the 1.5.2 code is in DefaultSearchHandler, in
searchMessageReceived() Line# 373:
if ( list.hasMore() )
{
<snip>
}
else
{
<snip>
// SPT - empty result lists should not accumulate registered
sessions
getSessionRegistry().removeOutstandingRequest( session,
req.getMessageId() );
}
I see there is a persistent search implementation that may also suffer the same
problem.
Comments appreciated.
> Memory Leak in Persistent search ?
> ----------------------------------
>
> Key: DIRSERVER-644
> URL: https://issues.apache.org/jira/browse/DIRSERVER-644
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
> Affects Versions: 1.5.4, 1.0-RC3
> Reporter: Emmanuel Lecharny
> Priority: Blocker
> Fix For: 1.5.5
>
> 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.
-
You can reply to this email to add a comment to the issue online.
