[
https://issues.apache.org/jira/browse/KAFKA-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Egerton updated KAFKA-10218:
----------------------------------
Description: If the {{DistributedHerder}} encounters issues reading to the
end of the config topic, it [takes note of this
fact|https://github.com/apache/kafka/blob/7db52a46b00eed652e791dd4eae809d590626a1f/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L1109]
by setting a field {{canReadConfigs}} to {{false}} and then acts accordingly
at the [start of its tick
loop|https://github.com/apache/kafka/blob/7db52a46b00eed652e791dd4eae809d590626a1f/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L319]
by trying again to read to the end of the config topic. However, if a
subsequent attempt to read to the end of the config topic succeeds, the
{{canReadConfigs}} field is never set back to {{true}} again, so no matter
what, the herder will always attempt to read to the end of the config topic at
the beginning of each tick. (was: If the {{DistributedHerder}} encounters
issues reading to the end of the config topic, it [takes note of this
fact|https://github.com/apache/kafka/blob/7db52a46b00eed652e791dd4eae809d590626a1f/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L1109]
by setting a field {{canReadConfigs}} to {{false}} and then acts accordingly
at the [start of its tick
loop|https://github.com/apache/kafka/blob/7db52a46b00eed652e791dd4eae809d590626a1f/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L319]
by trying again to read to the end of the config topic. However, if a
subsequent attempt to read to the end of the config topic succeeds, the
{{canReadConfigs}} field is never set back to {{true}} again, so no matter
what, the herder will always attempt to read to the end of the config topic at
the beginning of each tick.
This goes back beyond 1.0.0. I've added a handful of versions to {{Affects
Version/s}}, if anyone wants to add more feel free.)
> DistributedHerder's canReadConfigs field is never reset to true
> ---------------------------------------------------------------
>
> Key: KAFKA-10218
> URL: https://issues.apache.org/jira/browse/KAFKA-10218
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Reporter: Chris Egerton
> Assignee: Chris Egerton
> Priority: Major
>
> If the {{DistributedHerder}} encounters issues reading to the end of the
> config topic, it [takes note of this
> fact|https://github.com/apache/kafka/blob/7db52a46b00eed652e791dd4eae809d590626a1f/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L1109]
> by setting a field {{canReadConfigs}} to {{false}} and then acts accordingly
> at the [start of its tick
> loop|https://github.com/apache/kafka/blob/7db52a46b00eed652e791dd4eae809d590626a1f/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L319]
> by trying again to read to the end of the config topic. However, if a
> subsequent attempt to read to the end of the config topic succeeds, the
> {{canReadConfigs}} field is never set back to {{true}} again, so no matter
> what, the herder will always attempt to read to the end of the config topic
> at the beginning of each tick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
