[jira] [Comment Edited] (CAMEL-19285) Kafka consumer can flood brokers if TLS handshake fails and pollOnError is set to RECONNECT

["Mrinal (Jira)" <ji...@apache.org>]

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

Mrinal edited comment on CAMEL-19285 at 4/28/23 8:08 PM:
---------------------------------------------------------

[~dylan.piergies]  I am able to run the code and see that reconnection is not happening in a tight loop. the sample you have provided has 
{code:java}
reconnect-backoff-ms=1000
reconnect-backoff-max-ms: 10000{code}
The backoff logic is as per [ExponentialBackoff |https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/utils/ExponentialBackoff.java].

Based on this logic you should see that from the fourth retry onward, retries should happen approximately every 10sec. I am able to verify this from the sample you have provided.


was (Author: JIRAUSER297589):
[~dylan.piergies]  I am able to run the code and see that reconnection is not happening in a tight loop. the sample you have provided has 
{code:java}
reconnect-backoff-ms=1000{code}

This causes reconnection to happen every second. When I increased this value to 10 seconds, a reconnection attempt was made in 10 seconds.  So it seems to work as expected.  Am I missing something?


> Kafka consumer can flood brokers if TLS handshake fails and pollOnError is set to RECONNECT
> -------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-19285
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19285
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-kafka
>    Affects Versions: 3.20.2, 3.20.3
>            Reporter: Dylan Piergies
>            Priority: Major
>             Fix For: 3.20.5, 3.21.0, 4.0-RC1, 4.0
>
>
> The Kafka consumer does not respect reconnect backoff options when a TLS handshake fails if the consumer's {{pollOnError}} option is set to {{{}RECONNECT{}}}, resulting in reconnection attempts being made in a tight loop without delays, meaning that Camel applications consuming from Kafka topics can effectively mount a DDoS attack on the Kafka broker. This effect is amplified if concurrent consumers are in use, since each consumer thread is making its own connection attempts.
> Naturally, we found this out the hard way, in production, when another team put in place a firewall rule to allow connections from our consumers. The amount of TLS handshake traffic generated was sufficient to overwhelm the broker, resulting in an outage.
> I have created a small project to demonstrate the issue against a containerised Kafka broker here: [https://github.com/dylanpiergies/kafka-camel-flood-issue]
> This issue does not occur when a connection fails for other reasons (e.g. connection refused, connection timeout); in these cases the reconnect backoff behaves as expected.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)