[
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.patch
This patch fixes the problem for me.
In TcpipForwardSupport.sessionCreated() I wait for the ChennelForwardedTcpip
with a timeout, in a loop, and each time the timeout occurs I peak at the
acceptor that is trying to dispose in the other thread.
If that acceptor is disposing or disposed I give up on the port forward.
It may be more robust to wait with a longer timeout and no loop, this patch
simulates the behavior of the original unbounded wait while allowing the
acceptor to close simultaneously.
> 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-Stacks.test.txt, SSHD-123.patch,
> 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
