Hi, Jason, Thanks for the updated KIP. +1 from me.
Jun On Thu, Apr 4, 2019 at 2:26 PM Jason Gustafson <ja...@confluent.io> wrote: > Hi Jun, > > I have updated the KIP to remove `replica.selection.policy` from the > consumer configuration. Thanks for the suggestion. > > Best, > Jason > > On Wed, Mar 27, 2019 at 9:46 AM Jason Gustafson <ja...@confluent.io> > wrote: > > > @Jun > > > > Re; 200: It's a fair point that it is useful to minimize the client > > changes that are needed to get a benefit from affinity. I think the high > > level argument that this is mostly the concern of operators and should be > > under their control. Since there is a protocol bump here, users will have > > to upgrade clients at a minimum. An alternative would be to make > > "preferred" the default option for `replica.selection.policy`. But I > agree > > that the value of the configuration becomes less clear in this case. > > Overall this suggestion sounds good to me, but let me see if there is any > > additional feedback before I update the KIP. > > > > Re; 201: Ack. > > > > @Guozhang > > > > I think rack.id is still an easier and more reliable way for many users > > to determine local affinity. This lets us provide the simple rack-aware > > implementation which is probably sufficient for a fair number of use > cases > > and wouldn't require users to write any custom code. > > > > Thanks, > > Jason > > > > > > On Wed, Mar 27, 2019 at 9:05 AM Guozhang Wang <wangg...@gmail.com> > wrote: > > > >> Hello Jun, > >> > >> Regarding 200: if we assume that most client would not bother setting > >> rack.id at all and affinity can be determined w/o rack.id via TCP > header, > >> plus rack.id may not be "future-proof" additional information is needed > >> as > >> well, then do we still need to change the protocol of metadata request > to > >> add `rack.id`? > >> > >> > >> Guozhang > >> > >> On Tue, Mar 26, 2019 at 6:23 PM Jun Rao <j...@confluent.io> wrote: > >> > >> > Hi, Jason, > >> > > >> > Thanks for the KIP. Just a couple of more comments. > >> > > >> > 200. I am wondering if we really need the replica.selection.policy > >> config > >> > in the consumer. A slight variant is that we (1) let the consumer > always > >> > fetch from the PreferredReplica and (2) provide a default > >> implementation of > >> > ReplicaSelector that always returns the leader replica in select() for > >> > backward compatibility. Then, we can get rid of > >> replica.selection.policy in > >> > the consumer. The benefits are that (1) fewer configs, (2) affinity > >> > optimization can potentially be turned on with just a broker side > change > >> > (assuming affinity can be determined w/o client rack.id). > >> > > >> > 201. I am wondering if PreferredReplica in the protocol should be > named > >> > PreferredReadReplica since it's intended for reads? > >> > > >> > Jun > >> > > >> > On Mon, Mar 25, 2019 at 9:07 AM Jason Gustafson <ja...@confluent.io> > >> > wrote: > >> > > >> > > Hi All, discussion on the KIP seems to have died down, so I'd like > to > >> go > >> > > ahead and start a vote. Here is a link to the KIP: > >> > > > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-392%3A+Allow+consumers+to+fetch+from+closest+replica > >> > > . > >> > > > >> > > +1 from me (duh) > >> > > > >> > > -Jason > >> > > > >> > > >> > >> > >> -- > >> -- Guozhang > >> > > >
