[
https://issues.apache.org/jira/browse/ARTEMIS-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommy Lillehagen closed ARTEMIS-1559.
-------------------------------------
Resolution: Won't Fix
> 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)
