Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.20.2, 3.20.3
-
Moderate
Description
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.