kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Rao <...@confluent.io>
Subject Re: [VOTE] Vote for KIP-101 - Leader Epochs
Date Thu, 05 Jan 2017 00:50:01 GMT
Hi, Ben,

Thanks for the proposal. Looks good overall. A few comments below.

1. For LeaderEpochRequest, we need to include topic right? We probably want
to follow other requests by nesting partition inside topic? For
do we need to return leader_epoch? I was thinking that we could just return
an end_offset, which is the next offset of the last message in the
requested leader generation. Finally, would OffsetForLeaderEpochRequest be
a better name?

2. We should bump up both the produce request and the fetch request
protocol version since both include the message set.

3. Extending LeaderEpoch to include Returning Leaders: To support this, do
you plan to use the approach that stores  CZXID in the broker registration
and including the CZXID of the leader in /brokers/topics/[topic]/
partitions/[partitionId]/state in ZK?

4. Since there are a few other KIPs involving message format too, it would
be useful to consider if we could combine the message format changes in the
same release.



On Wed, Jan 4, 2017 at 9:24 AM, Ben Stopford <ben@confluent.io> wrote:

> Hi All
> We’re having some problems with this thread being subsumed by the
> [Discuss] thread. Hopefully this one will appear distinct. If you see more
> than one, please use this one.
> KIP-101 should now be ready for a vote. As a reminder the KIP proposes a
> change to the replication protocol to remove the potential for replicas to
> diverge.
> The KIP can be found here:  https://cwiki.apache.org/confl
> uence/display/KAFKA/KIP-101+-+Alter+Replication+Protocol+to+
> use+Leader+Epoch+rather+than+High+Watermark+for+Truncation <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-101+-
> +Alter+Replication+Protocol+to+use+Leader+Epoch+rather+
> than+High+Watermark+for+Truncation>
> Please let us know your vote.
> B

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message