You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Dylan Piergies (Jira)" <ji...@apache.org> on 2023/04/20 16:37:00 UTC

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

Dylan Piergies created CAMEL-19285:
--------------------------------------

             Summary: 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.3, 3.20.2
            Reporter: Dylan Piergies


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)