Thanks for the comments, Jun. 1. Good point. 2. Also makes sense. Usually the connection.max.idle.ms is high enough so the throttling is impacted.
I have updated the KIP to reflect the changes. Thanks, Jiangjie (Becket) Qin On Mon, Jan 8, 2018 at 6:30 PM, Jun Rao <j...@confluent.io> wrote: > Hi, Jiangjie, > > Sorry for the late response. The proposal sounds good overall. A couple of > minor comments below. > > 1. For throttling a fetch request, we could potentially just send an empty > response. We can return a throttle time calculated from a full response, > but only mute the channel on the server based on a throttle time calculated > based on the empty response. This has the benefit that the server will mute > the channel much shorter, which will prevent the consumer from rebalancing > when throttled. > > 2. The wiki says "connections.max.idle.ms should be ignored during the > throttle time X." This has the potential issue that a server may not detect > that a client connection is already gone until after an arbitrary amount of > time. Perhaps we could still just close a connection if the server has > muted it for longer than connections.max.idle.ms. This will at least bound > the time for a server to detect closed client connections. > > Thanks, > > Jun > > > On Mon, Nov 20, 2017 at 5:30 PM, Becket Qin <becket....@gmail.com> wrote: > > > Hi, > > > > We would like to start the voting thread for KIP-219. The KIP proposes to > > improve the quota communication between the brokers and clients, > especially > > for cases of long throttling time. > > > > The KIP wiki is following: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 219+-+Improve+quota+ > > communication > > > > The discussion thread is here: > > http://markmail.org/search/?q=kafka+KIP-219#query:kafka% > > 20KIP-219+page:1+mid:ooxabguy7nz7l7zy+state:results > > > > Thanks, > > > > Jiangjie (Becket) Qin > > >
