[ https://issues.apache.org/jira/browse/KAFKA-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111581#comment-17111581 ]
Jason Gustafson commented on KAFKA-10021: ----------------------------------------- [~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)