[jira] [Commented] (DIRMINA-1021) MINA-CORE does not remove sessions if exceptions occur while closing

["Carl Wicklow (JIRA)" <ji...@apache.org>]

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

Carl Wicklow commented on DIRMINA-1021:
---------------------------------------

In case it helps we see similar behavior in our application. Our IoHandler may not always see a sessionClosed (using Mina 2.0.0.13).

My analysis suggests that the destroy(session) here ....

{code:title=AbstractPollingIoProcessor.writeBuffer()|borderStyle=solid}
           try {
                localWrittenBytes = write(session, buf, length);
            } catch (IOException ioe) {
                // We have had an issue while trying to send data to the
                // peer : let's close the session.
                buf.free();
                session.close(true);
                destroy(session);  // HERE
                return 0;
            }
{code}

... means that by the time the scheduled remove actually occurs, the session state is CLOSING (because the destroy(session) invalidates the selection key).

Most often, we see a "Connection Reset By Peer" during the read that occurs before the write, and can deal with it in our exception handler. 

We'll sometimes see an inputClosed() (TCP half-close) - but neither closeNow() or closeOnFlush() will trigger a sessionClosed in the event that the write (which happens after the read) catches an exception (see also DIRMINA-1025, where the write may occur after a read that triggers an inputClosed()) - but, again, we have a chance here to handle it in our IoHandler.

But when an exception is first caught during the writeBuffer() call, we get no sessionClosed(), the closeFuture will never complete, and any pending writeFutures are left out in the cold too.
 

> 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)