On Tue, Nov 21, 2017, at 15:48, Ted Yu wrote: > For compatibility, I assume that the follower with new code would detect > when the leader doesn't support this feature and fall back to the > existing > full request. > > Cheers
In general, the protocol version which the brokers use to communicate with each other is controlled by the inter.broker.protocol.version configuration. Probably at some point we should switch this to use ApiVersionsRequest/Response, the same as how the client works. But that is outside the scope of this KIP. best, Colin > > On Tue, Nov 21, 2017 at 3:44 PM, Colin McCabe <cmcc...@apache.org> wrote: > > > On Tue, Nov 21, 2017, at 14:35, Ted Yu wrote: > > > Fill out the JIRA number. > > > > OK, will do. > > > > > > > > bq. If the leader receives an *IncrementalFetchRequest* with a UUID that > > > does not match that of the latest *FetchResponse* > > > > > > *By *latest *FetchResponse, you mean latest response for the broker Id, > > > right ?* > > > > Right. > > > > best, > > Colin > > > > > > > > *Cheers* > > > > > > On Tue, Nov 21, 2017 at 1:02 PM, Colin McCabe <cmcc...@apache.org> > > wrote: > > > > > > > Hi all, > > > > > > > > I created a KIP to improve the scalability and latency of FetchRequest: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > > > 227%3A+Introduce+Incremental+FetchRequests+to+Increase+ > > > > Partition+Scalability > > > > > > > > Please take a look. > > > > > > > > cheers, > > > > Colin > > > > > >
