[jira] [Resolved] (AMQ-6599) MQTT+NIO+SSL transport: transport.soTimeout is not applied during SSL handshake

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

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

Christopher L. Shannon resolved AMQ-6599.
-----------------------------------------
       Resolution: Fixed
    Fix Version/s: 5.14.4
                   5.15.0

> MQTT+NIO+SSL transport: transport.soTimeout is not applied during SSL handshake
> -------------------------------------------------------------------------------
>
>                 Key: AMQ-6599
>                 URL: https://issues.apache.org/jira/browse/AMQ-6599
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.14.3
>         Environment: Ubuntu 16.04
> openjdk version "1.8.0_121"
> OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13)
> OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
>            Reporter: Thomas Winterhalder
>            Assignee: Christopher L. Shannon
>             Fix For: 5.15.0, 5.14.4
>
>
> Currently I have trouble with many established TCP connections and threads hanging in the NIO+SSL handshake step. The hardware devices I use often have problems during SSL handshake and do not respond any more. So I thought configuring a transport.soTimeout value should solve the problem of hanging connections, because something like the MQTT  transport.defaultKeepAlive check is not applicable in this step yet. But setting transport.soTimeout=30000 had no effect.
> I made a remote debug session to the ActiveMQ broker and saw lots of threads waiting at NIOSSLTransport.java Line 430:
>     int keyCount = selector.select(this.getSoTimeout());
>     if (keyCount == 0 && this.getSoTimeout() > 0 && ((System.currentTimeMillis() - now) >= this.getSoTimeout())) {
>         throw new SocketTimeoutException("Timeout during handshake");
>     }
> At this point this.getSoTimeout returns always 0, which results in infinite timeout.
> I tried to figure out why the soTimeout setting works not as configured and found the code where the NIOSSLTransport object is created: TcpTransportServer.java function doHandleSocket(Socket socket). Here in line 580:
>     options.putAll(transportOptions);
> The soTimeout value is already removed from the transportOptions but it was apperantly not applied to the relevant object.
> To solve my problem for now I tried if the transport.soTimeout configuration works in a MQTT+SSL Stack (without using NIO) and it worked.
> May you please be so kind and solve this issue, so that the transport.soTimeout configurations works during SSL handshake and payload transfer as well for NIO.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)