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)
