activemq-dev mailing list archives

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


Oliver Deckert updated AMQ-5368:
    Attachment: NIOSSLTransport.patch 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:
>             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:
> org.apache.activemq.transport.nio.NIOSSLTransport.doHandshake()
> 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

View raw message