[
https://issues.apache.org/jira/browse/DIRMINA-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391495#comment-15391495
]
Emmanuel Lecharny commented on DIRMINA-1021:
--------------------------------------------
FTR, I'm conducting a full review on the session close. I already completed the
use case where we explicitely call {{NioSession.closeNow()}}, and it's pretty
complex. I have found at least one thing that need to be fixed : we call the
{{closeNow}} method a second time at the very end, which is totally useless.
Otherwise, the real problem with this method is that the session is not
actually closed *now*, but later on. Let me explain...
In order to really close the session, a few things need to be done :
* change the sessions state to 'closing'
* empty the message waiting to be written queue
* cancel the associated {{selectionKey}}
* close the associated {{Channel}}
The two last steps are done at the very end of the session's closing. IMO, that
should be the first thing to do, in order to avoid any incoming message to be
processed, because what happens is that when the first steps are completed, the
current thread has just pushed the session into a queue of session to be
removed, and this will be done only when we will loop on the {{select()}}
method again, and we may have to process incoming messages for this session,
which is utter nonsensical.
We can't change that at the moment, because the {{NioSession.getSelectiorKey}}
and {{NioSession.getChannel}} methods are package protected. But I do think
that the real issue is that there is no method in the {{IoSession}} that can be
called from {{closeNow}} method to disconnect the session. I'm going to add
such a call.
I still have to analyze the {{closeOnFlush()}} method, then there are other use
cases : typically when the connection is closed properly on the client side, or
when we get an exception on a session. That will be the next things I'll review.
> MINA-CORE does not remove sessions if exceptions occur while closing
> --------------------------------------------------------------------
>
> Key: DIRMINA-1021
> URL: https://issues.apache.org/jira/browse/DIRMINA-1021
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.8
> Environment: mina-ssh 0.14.0
> mina-core 2.0.8
> Multiple OSes / Java configurations:
> * Mac OS X El Capitan on Java 8 (1.8.0_60)
> * CentOS 6.4 on Java 8 (1.8.0_60)
> * CentOS 6.5 on Java 8 (1.8.0_20-b26).
> Reporter: Doug Kelly
> Attachments: attempt-removing-sessions-closing.patch
>
>
> MINA SSHD isn't removing sessions when using the MINA/NIO backend if an
> exception as received as the session is closing (such as a connection reset
> is received with data still in the write buffer). When this case happens, it
> seems that {{NioProcessor.getState}} returns the state as {{CLOSING}} (I'm
> assuming since the underlying channel is now closed), which means that the
> {{AbstractPollingIoProcessor.removeSessions()}} won't ever prune the session,
> since a {{CLOSING}} state is simply ignored. The result is a resource leak
> over time, since these sessions are never pruned (it's a slow leak, since
> entering this condition is racy – on my workstation, I can produce it through
> randomly interrupting connections anywhere from 1/6 to 1/10th of the time).
> (This may either be major or critical; reprioritize as necessary.)
> I specifically see this error with Gerrit 2.10.4 and Gerrit 2.11.5 (using
> mina-sshd 0.14.0 / mina-core 2.0.8), and it looks like the code path is
> unchanged in mina-sshd 1.0.0 / mina-core 2.0.9. I was unsure if this is
> specifically a bug in mina-core or, if it's something unique to mina-sshd. My
> local development system runs Mac OS X El Capitan on Java 8 (1.8.0_60), but
> I've also seen this on Linux (CentOS 6.4, again Java 1.8.0_60 and CentOS 6.5
> on Java 1.8.0_20-b26).
> The fix may be as simple as attempting to remove the session if {{OPENED}} or
> {{CLOSING}}, but I'm unsure what side-effects this may have with other
> backends. I'll be happy to test it locally, but I'm fairly ignorant when it
> comes to MINA's code.
> The attached patch (to mina-core) seems to resolve the issue by following the
> reproduction case I have on the [Gerrit issue
> tracker|https://code.google.com/p/gerrit/issues/detail?id=3685].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
