[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mina-dev
Subject:    [jira] [Updated] (SSHD-451) sshd-core DefaultTcpIpForwarder channel deadlocks on JRE 1.6.x
From:       "Sam Gardner (JIRA)" <jira () apache ! org>
Date:       2015-04-22 17:18:02
Message-ID: JIRA.12823060.1429716175000.77538.1429723082230 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/SSHD-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Sam Gardner updated SSHD-451:
-----------------------------
    Description: 
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.

  was:
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.

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.


> 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
> Environment: Java SE 6 [1.6.0_65-b14-466.1]
> 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)


[prev in list] [next in list] [prev in thread] [next in thread]