Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KAFKA-7440 Add leader epoch to fetch and list-offset request #6190

Merged
merged 12 commits into from
Feb 13, 2019

Conversation

mumrah
Copy link
Contributor

@mumrah mumrah commented Jan 24, 2019

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.

Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@hachikuji hachikuji self-assigned this Jan 25, 2019
Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, left a couple initial comments.

this.metadata.requestUpdate();
} else if (error == Errors.UNKNOWN_LEADER_EPOCH) {
log.warn("Received unknown leader epoch error in fetch for partition {}", tp);
this.metadata.requestUpdate();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the metadata update may not be needed. UNKNOWN_LEADER_EPOCH means the consumer's metadata has gotten ahead of the broker, so we can just retry. The only thing I am not sure is whether we need additional backoff logic before retrying.

@@ -992,6 +997,12 @@ private PartitionRecords parseCompletedFetch(CompletedFetch completedFetch) {
} else if (error == Errors.TOPIC_AUTHORIZATION_FAILED) {
log.warn("Not authorized to read from topic {}.", tp.topic());
throw new TopicAuthorizationException(Collections.singleton(tp.topic()));
} else if (error == Errors.FENCED_LEADER_EPOCH) {
log.warn("Received fenced leader epoch error in fetch for partition {}", tp);
this.metadata.requestUpdate();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we invalidate the fenced epoch somehow?

Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple comments. Are we going to handle the ListOffsets requests here as well?

@@ -992,6 +997,11 @@ private PartitionRecords parseCompletedFetch(CompletedFetch completedFetch) {
} else if (error == Errors.TOPIC_AUTHORIZATION_FAILED) {
log.warn("Not authorized to read from topic {}.", tp.topic());
throw new TopicAuthorizationException(Collections.singleton(tp.topic()));
} else if (error == Errors.FENCED_LEADER_EPOCH) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could probably add this to the errors on line 979 above. This is a "normal" error case, so I think we logging at debug level should be sufficient.

log.warn("Received fenced leader epoch error in fetch for partition {}", tp);
this.metadata.requestUpdate();
} else if (error == Errors.UNKNOWN_LEADER_EPOCH) {
log.warn("Received unknown leader epoch error in fetch for partition {}", tp);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be debug level?

@hachikuji
Copy link

retest this please

Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for the patch.

@hachikuji
Copy link

The failures are known flaky tests. I will go ahead and merge.

@hachikuji hachikuji merged commit b02b5b6 into apache:trunk Feb 13, 2019
pengxiaolong pushed a commit to pengxiaolong/kafka that referenced this pull request Jun 14, 2019
…#6190)

As part of KIP-320, we should add the expected leader epoch to Fetch and ListOffsets requests. This will allow us ultimately to detect log truncation.

Reviewers: Jason Gustafson <jason@confluent.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants