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)