[
https://issues.apache.org/jira/browse/SSHD-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998417#comment-14998417
]
Goldstein Lyor commented on SSHD-451:
-------------------------------------
First, NIO_WORKERS does have a meaning for MINA IO as well (less my area of
expertise though). Are you saying that with NIO this does not happen ? Is there
some way you can write a unit test that reproduces this problem with high
probability ?
> sshd-core DefaultTcpIpForwarder channel deadlocks on JRE 1.6.x
> --------------------------------------------------------------
>
> Key: SSHD-451
> URL: https://issues.apache.org/jira/browse/SSHD-451
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 0.10.0, 0.14.0, 1.0.0
> Environment: Java SE 6 [1.6.0_65-b14-466.1]
> Java SE 8 [1.8.0_51-b16]
> Reporter: Sam Gardner
> Labels: channel, deadlock
>
> I have a CentOS 6.4 system running {{httpd-2.4.9}} on port 8000.
> From this system, if I ssh to a {{MINA sshd-core 0.14.0}} server running on
> Java SE 6 {{1.6.0_65-b14-466.1}} using the following invocation
> {noformat}/usr/bin/ssh -R *:8000:localhost:8000 -p 2000 -N
> username@local-mina-server{noformat} I can reliably deadlock a remote forward
> channel after approximately five requests to {{localhost:8000}} on the system
> running MINA.
> After these requests I see one last line on the MINA server {noformat}
> 2015-04-22 10:11:10,406 | TRACE | NioProcessor-3 | TcpipClientChannel
> | org.apache.sshd.client.channel.AbstractClientChannel
> 195 | Waiting for lock on channel TcpipClientChannel[id=9, recipient=0],
> mask=130, cond=0
> {noformat} and then I cease to be able to access the remotely forwarded port
> until after the MINA server has been restarted, _even if I restart the client
> connection_.
> I believe the issue is related to this method in
> {{DefaultTcpipForwarder.java}}:
> {noformat}
> public void messageReceived(IoSession session, Readable message)
> throws Exception {
> TcpipClientChannel channel = (TcpipClientChannel)
> session.getAttribute(TcpipClientChannel.class);
> Buffer buffer = new Buffer();
> buffer.putBuffer(message);
> channel.waitFor(ClientChannel.OPENED | ClientChannel.CLOSED,
> Long.MAX_VALUE);
> channel.getInvertedIn().write(buffer.array(), buffer.rpos(),
> buffer.available());
> channel.getInvertedIn().flush();
> }
> {noformat}
> The channel lock {{wait}} request is given with a timeout of
> {{Long.MAX_VALUE}}, which seems unlikely to ever return in a synchronous
> environment like {{JRE 1.6.x}}. Initial testing indicates that a timeout of 5
> seconds appears to fix the issue, but this may have unforeseen consequences
> that I haven't run into yet.
> I cannot reproduce the issue on MINA SSHD 0.8.0, or when using JRE 1.7.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
