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

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

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

Dylan Piergies edited comment on CAMEL-19285 at 5/2/23 9:24 AM:
----------------------------------------------------------------

Yes, multiple consumers do amplify the problem, but I can still get much faster reconnects that configured with just a single consumer. I'll try to find some time to extract logs this afternoon and perhaps get to reproducing the problem more reliably.


was (Author: dylan.piergies):
Yes, multiple consumers do amplify the problem, but I can still get much faster reconnects that configured with just a single broker. I'll try to find some time to extract logs this afternoon and perhaps get to reproducing the problem more reliably.

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