mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Gardner (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SSHD-451) sshd-core DefaultTcpIpForwarder channel deadlocks on JRE 1.6.x
Date Wed, 22 Apr 2015 17:17:01 GMT

     [ 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.

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 {{/usr/bin/ssh -R *:8000:localhost:8000
-p 2000 -N username@local-mina-server
}}, 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.
> 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)

Mime
View raw message