[
https://issues.apache.org/jira/browse/AMQ-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871823#comment-15871823
]
ASF subversion and git services commented on AMQ-6599:
------------------------------------------------------
Commit 7c84aca59f89523c20daeced2b5f849d0fac0740 in activemq's branch
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7c84aca ]
AMQ-6599 - Properly apply soTimeout value to TcpTransport
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
(cherry picked from commit f6bf823dedba54dea40b597f1762ac6d7308ffa6)
> 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)
