[
https://issues.apache.org/jira/browse/CAMEL-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717856#comment-17717856
]
Mrinal commented on CAMEL-19285:
--------------------------------
Yes, the error is like this
{code:java}
2023-04-28 16:11:27.399 INFO 24501 --- [mer[test-topic]]
org.apache.kafka.clients.NetworkClient : [Consumer
clientId=consumer-00187c38-02c6-4914-82d7-53621ed2f645-1,
groupId=00187c38-02c6-4914-82d7-53621ed2f645] Node -1 disconnected.
2023-04-28 16:11:27.400 WARN 24501 --- [mer[test-topic]]
org.apache.kafka.clients.NetworkClient : [Consumer
clientId=consumer-00187c38-02c6-4914-82d7-53621ed2f645-1,
groupId=00187c38-02c6-4914-82d7-53621ed2f645] Connection to node -1
(localhost/127.0.0.1:9092) terminated during authentication. This may happen
due to any of the following reasons: (1) Authentication failed due to invalid
credentials with brokers older than 1.0.0, (2) Firewall blocking Kafka TLS
traffic (eg it may only allow HTTPS traffic), (3) Transient network issue.
{code}
> 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)
