[ 
https://issues.apache.org/jira/browse/ARTEMIS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256367#comment-15256367
 ] 

ASF subversion and git services commented on ARTEMIS-497:
---------------------------------------------------------

Commit 971a0a13bdff8130fb868c3a357e36586d6d56f0 in activemq-artemis's branch 
refs/heads/master from [~bgutjahr]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=971a0a1 ]

ARTEMIS-497 Prevent 10 second stalls when closing an SSL connection

When NettyConnection.classSSLAndChannel is called from the EventLoop,
waiting for the SSL handler to close will always take 10 seconds, because
the sslCloseFuture is from a task that is scheduled with the same
EventLoop. But since the EventLoop is a single threaded executor, it
will only be executed after the current task is completed.

Due to the single threaded nature of the EventLoop, all blocking calls
should be avoided. Therefore, I removed both awaitUninterruptibly calls
if the closing happens within an event loop tasks. As a side effect,
the annoying server log timeout warnings will go away.


> Sending a message sporadically stalls for ~10 seconds when SSL is enabled
> -------------------------------------------------------------------------
>
>                 Key: ARTEMIS-497
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-497
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Bernd Gutjahr
>
> When SSL is enabled in the NettyConnector configuration, we have sporadic 
> stalls for 10 seconds in message sends. The number of stalls seem to depend 
> on the current workload. We have seen it happening multiple times per minute, 
> but other cases with only a few stalls per hour.
> Every time we have a stall, there is also this log entry in the server 
> logfile:
>  AMQ212040: Timed out waiting for netty ssl close future to complete



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to