activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Deckert (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-5368) SSL handshake stalls broker with NIO
Date Thu, 25 Sep 2014 07:54:33 GMT

     [ https://issues.apache.org/jira/browse/AMQ-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oliver Deckert updated AMQ-5368:
--------------------------------
    Attachment: NIOSSLTransport.patch

NIOSSLTransport.java with 2 modifications:
- run (first) delegated task synchronously
- add some wait cycles for channel reads (to prevent too frequent reads)

debug log statements could be removed, of course

> 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
>         Environment: java version "1.7.0_65"
>            Reporter: Oliver Deckert
>              Labels: nio, ssl
>         Attachments: NIOSSLTransport.patch
>
>
> using NIOSSL transport, SSL handshakes for ~5000 connections easily stalls 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)

Mime
View raw message