[
https://issues.apache.org/jira/browse/DIRMINA-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375908#comment-16375908
]
Jonathan Valliere commented on DIRMINA-1076:
--------------------------------------------
The problem is no atomic method of knowing of an {{Session}} has already been
removed or not. Its more than just "duplicates" inside of the queue because it
could be added back to the queue after it was removed. The tests are showing
that it is very possible to add to the remove queue, remove, then another
thread add it back to the remove queue.
I covered that as an option under the heading *Option 1*. The problem cannot
be fixed using locks unless both the {{scheduleRemove()}} and everything after
{{select()}} inside of {{processor.run()}} to be inside of the lock. It would
require that {{scheduleRemove()}} only happen while the processor is performing
a {{select()}} in order to guarantee order. Even with two large critical
sections, there is the nasty problem of being able to use selector.keys{{()}}
to verify if the {{session}} is actually registered with that {{processor}}.
To correctly fix it with locks might require extra {{selectNow()}} calls in
order to update {{selector.keys()}}. Its just ugly.
The other alternative might be to completely gut the {{nSessions}} mechanic and
just use {{selector.keys().size()}} to determine when to dispose of the
processor.
> 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)
