[
https://issues.apache.org/jira/browse/AMQ-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871820#comment-15871820
]
ASF subversion and git services commented on AMQ-6599:
------------------------------------------------------
Commit f6bf823dedba54dea40b597f1762ac6d7308ffa6 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=f6bf823 ]
AMQ-6599 - Properly apply soTimeout value to TcpTransport
https://issues.apache.org/jira/browse/AMQ-6599
The soTimeout value needs to be applied to the TcpTransport as well as
the socket because the NIO transports use the value later on when
establishing a connection
> 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
>
> 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)
