[
https://issues.apache.org/jira/browse/KAFKA-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111493#comment-17111493
]
Arjun Satish commented on KAFKA-10021:
--------------------------------------
[~hachikuji] [~skaundinya] do consumers in a JVM share a connection to a broker
or do they all create their own connections? if they share a connection, then
this problem can occur if a connector/task has its consumer overrides that sets
a high `fetch.max.wait.ms`. In this case, the worker should not allow
overriding this value in a connector to more than what is allowed by the
workerSyncTimeoutMs.
> When reading to the end of the config log, check if fetch.max.wait.ms is
> greater than worker.sync.timeout.ms
> ------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-10021
> URL: https://issues.apache.org/jira/browse/KAFKA-10021
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Reporter: Sanjana Kaundinya
> Priority: Major
>
> Currently in the Connect code in DistributedHerder.java, we see the following
> piece of code
>
> {{ if (!canReadConfigs && !readConfigToEnd(workerSyncTimeoutMs))
> return; // Safe to return and tick immediately because
> readConfigToEnd will do the backoff for us}}
> where the workerSyncTimeoutMs passed in is the timeout given to read to the
> end of the config log. This is a bug as we should check if fetch.wait.max.ms
> is greater than worker.sync.timeout.ms and if it is, use
> worker.sync.timeout.ms as the fetch.wait.max.ms. A better fix would be to use
> the AdminClient to read to the end of the log, but at a minimum we should
> check the configs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
