You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Dejan Bosanac (JIRA)" <ji...@apache.org> on 2015/07/06 12:29:04 UTC

[jira] [Commented] (AMQ-5368) SSL handshake stalls broker with NIO

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

Dejan Bosanac commented on AMQ-5368:
------------------------------------

Hi Oliver, can you by any chance provide a test case that reproduces this problem? It would help verify the fix and protect it in the future.

> SSL handshake stalls broker with NIO
> ------------------------------------
>
>                 Key: AMQ-5368
>                 URL: https://issues.apache.org/jira/browse/AMQ-5368
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.8.0, 5.9.0, 5.10.0
>         Environment: java version "1.7.0_65"
>            Reporter: Oliver Deckert
>            Assignee: Dejan Bosanac
>              Labels: nio, ssl
>         Attachments: NIOSSLTransport.patch
>
>
> using NIOSSL transport, SSL handshakes for ~5000 connections easily stall a broker taking 100% CPU
> I'm using version ActiveMQ 5.8, but it occurs on 5.9, 5.10 versions as well
> doing some profiling, it showed up that the SSL handshake on broker side eats up ~90% of overall CPU time
> by checking just the handshake status in very high frequency
> top 3 methods sorted by own processor time:
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.getHandshakeStatus()
> org.apache.activemq.transport.nio.NIOSSLTransport.doHandshake()
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.getHSStatus(javax.net.ssl.SSLEngineResult$HandshakeStatus)
> the reason is the asynchronous nature of the SSL handshake with NIO, especially the execution of delegated tasks:
> - NIOSSLTransport.doHandshake() executes delegated tasks using a TaskRunnerFactory asynchronously
> - in the meantime it loops calling SSLEngine.getHandshakeStatus()
> to improve the situation I did the following changes:
> - run delegated tasks synchronously in method doHandshake (handshake status NEED_TASK) instead of asynchronously
> - added some small wait cycles in method secureRead as there is not always data available with NIO (to further reduce the number of calls to SSLEngine.getHandshakeStatus)
> after these changes the SSL handshake for several thousand connections in parallel was not a problem anymore



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