[jira] [Issue Comment Deleted] (KAFKA-10021) When reading to the end of the config log, check if fetch.max.wait.ms is greater than worker.sync.timeout.ms

["Jason Gustafson (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Gustafson updated KAFKA-10021:
------------------------------------
    Comment: was deleted

(was: [~wicknicks] Each consumer instance has a separate connection to the brokers. This issue wouldn't be a problem if we used a separate AdminClient to query the end offsets.)

> 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)