activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tommy Lillehagen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1559) Connecting with reconnectAttempts=-1 and sslEnabled=false to an acceptor with sslEnabled=true results in high volume of handshake timeouts
Date Wed, 13 Jun 2018 13:00:00 GMT

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

Tommy Lillehagen commented on ARTEMIS-1559:
-------------------------------------------

Okay, thanks for getting back to us.

We have mitigated the DoS attack vector in a different way, so I'll close this ticket now.

Cheers

> 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)

Mime
View raw message