Hey Jason, Thanks for the KIP! It is pretty useful.
At high level the new set of reset policies may be a bit complicated and confusing to users. I am wondering whether we can simplify it. A few questions below: - The KIP says that, with auto.offset.reset="closest", timestamp is used to find offset if truncation offset is unknown. It seems that if consumer knows the timestamp of the last message, then the consumer should also know the (offset, leaderEpoch) of the last message which can then be used for find the truncation offset. Can you explain why truncation offset is unknown in this case? - How does consumer differentiates between "Offset out of rnage (too low)" and "Offset out of range (unknown truncation offset)", i.e. the two columns in table provided in the KIP? - It is probably a typo. Maybe fix "This is not the last The" in the Proposed Section. Thanks, Dong On Mon, Jun 25, 2018 at 9:17 AM, Jason Gustafson <ja...@confluent.io> wrote: > Hey All, > > I wrote up a KIP to handle one more edge case in the replication protocol > and to support better handling of truncation in the consumer when unclean > leader election is enabled. Let me know what you think. > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-320%3A > +Allow+fetchers+to+detect+and+handle+log+truncation > > Thanks to Anna Povzner and Dong Lin for initial feedback. > > Thanks, > Jason >
