-
Notifications
You must be signed in to change notification settings - Fork 29
Fix #204: Have the consuming client refresh its metadata if the partition leadership changes. #206
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix. Left some comments.
topicMetadata, err = ts.describeCanaryTopic() | ||
if err != nil { | ||
return result, err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a side bug fix, right? Before this change, we'll just return empty result even if the topic is created, which is unexpected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it is because I want topicMetadata
to be populated in the case where the topic has just been created so that I can do ts.currentLeaders(topicMetadata)
later on in the method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that worth a code comment?
I want to write unit tests to help with the refactoring. Please review #207 first. I can then build the unit tests on top of that. |
You are right. Thanks. |
…e partition leadership changes This minimises the time the canary spends consumer from followers after the partition leadership changes on the broker, and so avoid end to end latency measure being skewed. Signed-off-by: kwall <[email protected]>
Supporting unit test added. |
topicMetadata, err = ts.describeCanaryTopic() | ||
if err != nil { | ||
return result, err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that worth a code comment?
Signed-off-by: kwall <[email protected]>
@tombentley comment added. |
This minimises the time the canary spends consuming from followers after the partition leadership changes on the cluster. This avoid the end to end latency measure being skewed by the additional latency introduced by the highwatermark propagation between leader/followers. I left a fuller explanation on this comment: #204 (comment)