You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Norval Hope (JIRA)" <ji...@apache.org> on 2008/09/17 10:15:44 UTC
[jira] Created: (DIRSERVER-1258) memory leak (outstanding requests)
in SearchHandler
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.
[jira] Updated: (DIRSERVER-1258) memory leak (outstanding requests)
in SearchHandler
Posted by "Norval Hope (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norval Hope updated DIRSERVER-1258:
-----------------------------------
Attachment: DIRSERVER-1258-search-handler.patch
This patch addresses what i see as the leaks by deregistering all requests in a finally block. It passes all the tests run automatically by "mvn install" - is that sufficient sanity testing?
Thanks
> 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.
[jira] Commented: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631784#action_12631784 ]
Emmanuel Lecharny commented on DIRSERVER-1258:
----------------------------------------------
About #3 : Persistent seacrh is a special search. It's set by a controlt, and stopped by another control. There is no need to abandon it, and it won't timeOut or sizeOut. So same as #2 regarding storing this request in the session.
> 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.
[jira] Resolved: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRSERVER-1258.
------------------------------------------
Resolution: Fixed
I think it's fixed with : http://svn.apache.org/viewvc?rev=696362&view=rev
> 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.
[jira] Closed: (DIRSERVER-1258) memory leak (outstanding requests)
in SearchHandler
Posted by "Norval Hope (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norval Hope closed DIRSERVER-1258.
----------------------------------
Thanks Emmanuel. Have verified the modified patch on Windoze.
> 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
> Assignee: Emmanuel Lecharny
> 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.
[jira] Commented: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631827#action_12631827 ]
Emmanuel Lecharny commented on DIRSERVER-1258:
----------------------------------------------
I was dead wrong on #3 : we need to keep the request in the session, until it dies.
So the proposed patch is not good. We have to add a 'finally' statement, that's granted, but we some few controls. The request should be removed if :
- it was not a persistent search
or
- it was a persistent search AND we've got an exception.
Now, we also have to remove the request from the session if the persistent search is stopped.
> 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.
[jira] Commented: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631830#action_12631830 ]
Emmanuel Lecharny commented on DIRSERVER-1258:
----------------------------------------------
Seems to be done in the AbandonRequest code, for abandonRequests :
public class AbandonHandler extends LdapRequestHandler<AbandonRequest>
{
public void handle( LdapSession session, AbandonRequest request ) throws Exception
{
...
session.abandonOutstandingRequest( request.getAbandoned() );
....
> 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.
[jira] Assigned: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny reassigned DIRSERVER-1258:
--------------------------------------------
Assignee: Emmanuel Lecharny
> 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
> Assignee: Emmanuel Lecharny
> 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.
[jira] Commented: (DIRSERVER-1258) memory leak (outstanding
requests) in SearchHandler
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631786#action_12631786 ]
Emmanuel Lecharny commented on DIRSERVER-1258:
----------------------------------------------
I have to double check that the OutstandingRequest element is removed from the session when the request is done, or when an exception is thrown.
Seems to be a very good and valid issue. Thanks Norval !
> 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.