directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Temple (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-644) Memory Leak in Persistent search ?
Date Mon, 22 Jun 2009 13:50:07 GMT

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


Mime
View raw message