You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by GitBox <gi...@apache.org> on 2022/10/12 13:27:22 UTC
[GitHub] [kafka] dajac opened a new pull request, #12734: KAFKA-14255; Return an empty record instead of an OffsetOutOfRangeException when fetching from a follower without a leader epoch
dajac opened a new pull request, #12734:
URL: https://github.com/apache/kafka/pull/12734
Fetching from a follower is only allowed from version 11 of the fetch request. Our intent was to allow it assuming that those would also implement KIP-320 (leader epoch). It turns out that some clients use version 11 without KIP-320 and the broker allows this. The issue is that we don't know whether the client fetches from the follower based on the order of the leader or by mistake e.g. based on stale metadata. The latter means that a client could end up on the follower with an offset that the follower does not have yet. Instead of returning OffsetOutOfRangeException, we return an empty batch to the client with the expectation that the client will retry and eventually refresh its metadata. Note that we only do this if the client does not provide a leader epoch and use version 11. If the client uses version 11 and provided a leader epoch, it knows that it has to consult the leader on an OffsetOutOfRangeException error.
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [kafka] ijuma commented on a diff in pull request #12734: KAFKA-14255; Return an empty record instead of an OffsetOutOfRangeException when fetching from a follower without a leader epoch
Posted by GitBox <gi...@apache.org>.
ijuma commented on code in PR #12734:
URL: https://github.com/apache/kafka/pull/12734#discussion_r995790517
##########
core/src/main/scala/kafka/cluster/Partition.scala:
##########
@@ -1339,6 +1341,26 @@ class Partition(val topicPartition: TopicPartition,
}
}
+ // Fetching from a follower is only allowed from version 11 of the fetch request. Our intent
+ // was to allow it assuming that those would also implement KIP-320 (leader epoch). It turns
+ // out that some clients use version 11 without KIP-320 and the broker allows this. The issue
+ // is that we don't know whether the client fetches from the follower based on the order of
+ // the leader or by mistake e.g. based on stale metadata. The latter means that a client could
+ // end up on the follower with a offset that the follower does not have yet. Instead of returning
+ // OffsetOutOfRangeException, we return an empty batch to the client with the expectation that
+ // the client will retry and eventually refresh its metadata. Note that we only do this if the
+ // client does not provide a leader epoch and use version 11.
+ if (isFollower && !currentLeaderEpoch.isPresent && fetchOffset > initialLogEndOffset) {
Review Comment:
Unclean leader election, fetch version > 11 and no KIP-320 implemented seems like it would be rare enough not to make things too complex for it. KIP-320 is being implemented for librdkafka as we speak and we should file an issue on Sarama's and kafkajs's issue tracker for them to implement it too. That's the only way to have truly sane behavior.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [kafka] dajac commented on pull request #12734: KAFKA-14255; Return an empty record instead of an OffsetOutOfRangeException when fetching from a follower without a leader epoch
Posted by GitBox <gi...@apache.org>.
dajac commented on PR #12734:
URL: https://github.com/apache/kafka/pull/12734#issuecomment-1276174598
This is an potential alternative to https://github.com/apache/kafka/pull/12674.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [kafka] dajac closed pull request #12734: KAFKA-14255; Return an empty record instead of an OffsetOutOfRangeException when fetching from a follower without a leader epoch
Posted by GitBox <gi...@apache.org>.
dajac closed pull request #12734: KAFKA-14255; Return an empty record instead of an OffsetOutOfRangeException when fetching from a follower without a leader epoch
URL: https://github.com/apache/kafka/pull/12734
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [kafka] hachikuji commented on a diff in pull request #12734: KAFKA-14255; Return an empty record instead of an OffsetOutOfRangeException when fetching from a follower without a leader epoch
Posted by GitBox <gi...@apache.org>.
hachikuji commented on code in PR #12734:
URL: https://github.com/apache/kafka/pull/12734#discussion_r995118293
##########
core/src/main/scala/kafka/cluster/Partition.scala:
##########
@@ -1339,6 +1341,26 @@ class Partition(val topicPartition: TopicPartition,
}
}
+ // Fetching from a follower is only allowed from version 11 of the fetch request. Our intent
+ // was to allow it assuming that those would also implement KIP-320 (leader epoch). It turns
+ // out that some clients use version 11 without KIP-320 and the broker allows this. The issue
+ // is that we don't know whether the client fetches from the follower based on the order of
+ // the leader or by mistake e.g. based on stale metadata. The latter means that a client could
+ // end up on the follower with a offset that the follower does not have yet. Instead of returning
+ // OffsetOutOfRangeException, we return an empty batch to the client with the expectation that
+ // the client will retry and eventually refresh its metadata. Note that we only do this if the
+ // client does not provide a leader epoch and use version 11.
+ if (isFollower && !currentLeaderEpoch.isPresent && fetchOffset > initialLogEndOffset) {
Review Comment:
I guess the main downside of this is that notification about genuine out of range errors will be delayed. The only case I can think of where this could happen is an unclean election. That might be an acceptable tradeoff, but I wonder if we can do better. The thought I had before is to use the log end offset from the leader that we learn through `Fetch` requests. The tricky thing is ensuring we are not relying on a stale value. I don't know of an easy way to solve that without holding onto the `Produce` request until the next `Fetch` is received. That could be complicated to implement I guess. Any alternatives?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org