[
https://issues.apache.org/jira/browse/DIRMINA-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16359966#comment-16359966
]
Jonathan Valliere commented on DIRMINA-1076:
--------------------------------------------
Here is the patch to fix your issue; it also passes maven:test. It passes the
tests but is not the final patch because I have some concerns about it long
term.
{code:java}
diff --git
a/mina-core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoProcessor.java
b/mina-core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoProcessor.java
index 79885fa..503df41 100644
---
a/mina-core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoProcessor.java
+++
b/mina-core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoProcessor.java
@@ -661,7 +661,9 @@
// And manage removed sessions
nSessions -= removeSessions();
-
+
+ assert nSessions > -1 : "Number of Sessions has gone
negative";
+
// Last, not least, send Idle events to the idle sessions
notifyIdleSessions(currentTime);
@@ -695,9 +697,8 @@
for (Iterator<S> i = allSessions(); i.hasNext();) {
IoSession session = i.next();
- scheduleRemove((S) session);
-
if (session.isActive()) {
+ scheduleRemove((S) session);
hasKeys = true;
}
}{code}
Emmanual, while this patch fixes the problem Christoph is seeing. I am
concerned that relying on this change could cause a problem where the
SelectionKey.isValid() i.e. `session.isActive()` is false but the Session was
not previously removed correctly. The AbstractIoProcessor is relying on the
validity of the SelectionKey and the Set<SelectionKey> to internally manage
active sessions which is a really bad move because the SelectionKeys can become
invalid totally independent of the AbstractIoProcessor which could leave
pending writing data and other things hanging forever. Fundamentally, the
problem is that, in the 2.0 master the Sessions are being removed TWICE from
AbstractIoProcessor leaving the Session Counter in the Negative. One way to
fix the problem safely is to store all the Sessions for the IoProcessor as a
List and use that as the master list of 'active' Sessions but I don't know if
there is some lazy Session stealing between IoProcessors in Mina which could
conflict with that idea.
> 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
> 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)
