[jira] [Updated] (ARTEMIS-1559) Connecting with reconnectAttempts=-1 and sslEnabled=false to an acceptor with sslEnabled=true results in high volume of handshake timeouts

["Justin Bertram (JIRA)" <ji...@apache.org>]

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

Justin Bertram updated ARTEMIS-1559:
------------------------------------
    Summary: Connecting with reconnectAttempts=-1 and sslEnabled=false to an acceptor with sslEnabled=true results in high volume of handshake timeouts  (was: Repeated retries of unencrypted traffic to SSL-enabled broker causes OOM exception)

> Connecting with reconnectAttempts=-1 and sslEnabled=false to an acceptor with sslEnabled=true results in high volume of handshake timeouts
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1559
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1559
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.3.0, 2.4.0
>            Reporter: Tommy Lillehagen
>            Priority: Major
>         Attachments: mem-leak-source.png, mem-leak.png
>
>
> Repro steps:
>  * We have a broker (A) set up with SSL enabled (using Artemis v2.4 / v2.3)
>  * A client (B) set up to use plain (non-TLS) communication (same version of Artemis)
>  * Trying to establish a connection between (B) and (A) triggers multiple retries
>  * Each message gets, from what I can tell, rejected quickly by (A), but each iteration leaks heap memory
>  * Due to the number of retries in a short amount a time (~1000s from what I can tell) causes the above to grow the heap by 470M or so within less than 10 seconds (the set timeout)
>  * This consequently results in an out of memory exception
> The above behaviour is observed in both version 2.3 and 2.4.
> We've tested older versions (2.1 and 2.2), and neither of those manifest the same problem.
> I've run some profiling on (A), and {{NettyAcceptor.initChannel}} ({{getSslHandler()}}) seems to be a critical point (will include screenshots).
> That being said, most of the accumulated heap memory seems to be claimable and is mostly collected during the next GC cycle in the tests that I've run.
> Source: https://github.com/corda/corda/pull/2252



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)