[
https://issues.apache.org/jira/browse/AMQ-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871825#comment-15871825
]
Christopher L. Shannon commented on AMQ-6599:
---------------------------------------------
The issue was the soTimeout value was being remove from the options map after
being applied to the Socket so it was not applied on the TcpTransport itself.
For normal transports this is not a problem but for the NIO transports this
causes the soTimeout value to always be 0 later on when it is used on
selector.select(soTimeout) as you found. I'm planning on working on the 5.14.4
release next week so the fix should be out soon.
> 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)
