[jira] [Reopened] (SSHD-786) Clients can't authenticate after unexpected exception in Nio2Acceptor
[
https://issues.apache.org/jira/browse/SSHD-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reopened SSHD-786:
-
Seems that under certain circumstances, the code in {{onFailed}} that attempts
to re-engage the _accept_ call fails with {{AcceptPendingException}}.
{code:java|title=Nio2Acceptor#AcceptCompletionHandler#onFailed}
try {
// Accept new connections
socket.accept(address, this);
} catch (Throwable t) {
// Do not call failed(t, address) to avoid infinite recursion
log.error("Failed (" + t.getClass().getSimpleName()
+ " to re-accept new connections on " + address
+ ": " + t.getMessage(), t);
}
{code}
according to the exception's documentation
{quote}
Unchecked exception thrown when an attempt is made to initiate an accept
operation on a channel and a previous accept operation has not completed.
{quote}
Since this happens intermittently and more often on _Linux_ rather than
_Windows_ (as a matter of fact I have not encountered it on _Windows_ yet), it
seems like either some race condition or different code in different JDK
versions. We need to find some way to "complete" the handling of {{onFailed}}
and somehow signal that we want to re-accept connections, while at the same
time avoiding an infinite failure loop.
> Clients can't authenticate after unexpected exception in Nio2Acceptor
> -
>
> Key: SSHD-786
> URL: https://issues.apache.org/jira/browse/SSHD-786
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.6.0
> Environment: Windows
>Reporter: masc
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 1.7.0
>
>
> {code}
> 2017-11-28 15:26:54,808 11566202 sshd-SshServer[434a2a10]-nio2-thread-4
> org.apache.sshd.common.io.nio2.Nio2Acceptor WARN - Caught IOException while
> accepting incoming connection from /0:0:0:0:0:0:0:0:13003: The specified
> network name is no longer available.
> java.io.IOException: The specified network name is no longer available.
> at sun.nio.ch.Iocp.translateErrorToIOException(Iocp.java:309)
> at sun.nio.ch.Iocp.access$700(Iocp.java:46)
> at sun.nio.ch.Iocp$EventHandlerTask.run(Iocp.java:399)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As soon as this exception occurs once, clients can still connect but will
> fail to authenticate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DIRMINA-1076) Leaking NioProcessors/NioSocketConnectors hanging in call to dispose
[ https://issues.apache.org/jira/browse/DIRMINA-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378358#comment-16378358 ] Christoph John edited comment on DIRMINA-1076 at 2/27/18 10:30 AM: --- Just a question: does it make sense to add the tests I created for DIRMINA-1076 and DIRMINA-1077 to the project? They probably should be on @Ignore though since they run in an endless loop. OTOH when they are ignored they probably don't make sense to be included either. ;) was (Author: chrjohn): Just a question: does it make sense to add the tests I created for DIRMINA-1076 and DIRMINA-1077 to the project? They probably should be on @Ignore though since they run in an endless loop. OTOH when they are ignored they probably don't make sense ti be included either. ;) > 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 > Components: Core >Affects Versions: 2.0.16 >Reporter: Christoph John >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.0.17 > > 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)
[jira] [Commented] (DIRMINA-1076) Leaking NioProcessors/NioSocketConnectors hanging in call to dispose
[ https://issues.apache.org/jira/browse/DIRMINA-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378358#comment-16378358 ] Christoph John commented on DIRMINA-1076: - Just a question: does it make sense to add the tests I created for DIRMINA-1076 and DIRMINA-1077 to the project? They probably should be on @Ignore though since they run in an endless loop. OTOH when they are ignored they probably don't make sense ti be included either. ;) > 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 > Components: Core >Affects Versions: 2.0.16 >Reporter: Christoph John >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.0.17 > > 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)
[jira] [Commented] (DIRMINA-1076) Leaking NioProcessors/NioSocketConnectors hanging in call to dispose
[ https://issues.apache.org/jira/browse/DIRMINA-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378338#comment-16378338 ] Christoph John commented on DIRMINA-1076: - Hi guys, everything looking good on my end. Thanks for the quick turnaround and your help. :) Cheers, Chris. > 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 > Components: Core >Affects Versions: 2.0.16 >Reporter: Christoph John >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.0.17 > > 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)
