Hi Jason, Thanks for the KIP. It looks good to me overall.
1. Just clarifying the "CurrentVersion" field in the newly proposed protocol. Does it contains the same value as zkVersion that controller get from ZK? 2. As for the comment in the KIP: "We can either await the update or we can send a new update with the current version. If we did the latter, then we would have multiple pending inflights using the same version." My understanding is that it is the controller who acts as the source of truth for "currentVersion", in which case I think there's little latency benefits to send multiple pending requests with the same version, since which-ever arrives controller first would cause the zkVersion to be bumped and therefore the rest of the requests would be rejected with "INVALID_ISR_VERSION". So I'd favor just wait the update response from the current inflight request before sending out the next request -- admittedly this requires a bit more complicated implementation on the brokers, but maybe we can generalize the request queue module on controller for this purpose? Guozhang On Sun, Jul 28, 2019 at 10:32 AM Colin McCabe <cmcc...@apache.org> wrote: > Hi Jason, > > This looks good. > > If the AlterIsr request returns a higher ZK version than the one the > broker currently has, will the broker use that as its new ZK version? I > suppose this could happen if some of the updates the controller pushed out > were not received or not received yet by the broker in question. > > best, > Colin > > > On Fri, Jul 26, 2019, at 09:43, Jason Gustafson wrote: > > Hi All, > > > > I have written a proposal to change the way leaders make ISR > > modifications: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-497%3A+Add+inter-broker+API+to+alter+ISR > . > > Have a look and let me know what you think. > > > > Thanks, > > Jason > > > -- -- Guozhang
