[
https://issues.apache.org/jira/browse/SSHD-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Kuker updated SSHD-123:
----------------------------
Attachment: SSHD_123_Test.java
This is a test that reliably exposes the problem, at least on my system. It
creates a port forward, makes a connection through it and immediately severs
the client connection.
The test looks through the stack traces of the NioAcceptor threads to look for
this specific condition, and times out after 20 seconds. Its probably not a
good test to include in the automated unite tests.
> TcpipForward race condition & deadlock on client disconnect.
> ------------------------------------------------------------
>
> Key: SSHD-123
> URL: https://issues.apache.org/jira/browse/SSHD-123
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 0.3.0, 0.5.0, 0.6.0
> Environment: I am able to reproduce this every single time on my quad
> core windows 7 machine.
> Reporter: Bill Kuker
> Attachments: SSHD_123_Test.java
>
>
> If a client with an active remote port forward disconnects at about the same
> time a new connection comes in to that port forward two NioProcessor threads
> end up deadlocked in TcpipForwardSupport, at the following spots:
> NioProcessor-14 stuck at
> org.apache.sshd.server.session.TcpipForwardSupport.sessionCreated(...):
> OpenFuture future = channel.open().await();
> NioProcessor-2 stuck at
> org.apache.sshd.server.session.TcpipForwardSupport.close():
> acceptor.dispose();
> It appears that the new connection to the port forward is trying to create a
> new channel over a session that is currently trying to close. Both threads
> end up waiting on different objects, and are never notified.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
