[ 
https://issues.apache.org/jira/browse/DIRMINA-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375914#comment-16375914
 ] 

Emmanuel Lecharny commented on DIRMINA-1076:
--------------------------------------------

Right. One of the problem is that the session state is always computed, it's 
never hold by the session, otherwise we would have been able to check if the 
session is currently being removing, forbidding another removal to be done... 
Option 2 is trying to mimic that.

Another possibility might be to rethink the way the session state is handled : 
* we add a new state (REMOVING) in the {{SessionState}} enum
* We add a field in the {{NioSession}} class which holds the session's state
* We set/check this state when we call {{getState}} or when we call 
{{scheduleRemove}}

It may be less likely to create a memory leak. 

At this point, it's just an idea, I don't foresee all the pros and cons of this 
approach, I need to sleep over it (it's 5AM atm...)

> Leaking NioProcessors/NioSocketConnectors hanging in call to dispose
> --------------------------------------------------------------------
>
>                 Key: DIRMINA-1076
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-1076
>             Project: MINA
>          Issue Type: Bug
>    Affects Versions: 2.0.16
>            Reporter: Christoph John
>            Assignee: Jonathan Valliere
>            Priority: Major
>         Attachments: mina-dispose-hang.txt, mina-test-log.txt, 
> mina-test-patch.txt
>
>
> Follow-up to mailing list discussion.
> I was now able to reproduce the problem with a MINA test. Or let's say I did 
> the brute-force approach by re-running one test in an endless loop.
> I have attached a patch of AbstractIoServiceTest (against 
> [https://github.com/apache/mina/tree/2.0]) and a stack trace. After a few 
> loops the test is stuck. You can see a lot of threads hanging in dispose() 
> and the test is stuck when it tries to dispose the acceptor.
>  
> What is a little strange is that the javadoc says that 
> connector.dispose(TRUE) should not be called from an IoFutureListener, but in 
> the test it is done anyway. However, changing the parameter to FALSE does not 
> help either.
>  
>  Is there anything that can be done to prevent this hang?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to