Hi, Lucas, Thanks for the KIP. A few comments below.
1. As Eno mentioned in the discussion thread, I am wondering how much of this is still an issue after KAFKA-5642. With that fix, the requests from the controller to the brokers are batched in all the common cases. Have you deployed Kafka 1.1? What's the request queue time and the request queue size that you have observed in production? 2. For the request queue, currently we can also bound it by size through queued.max.request.bytes. Should we consider the same for the control queue? 3. Implementation wise, currently the request handler threads just block on the request queue when the queue is empty. With two queues, it seems that we need to wake up a request handler thread blocked on one queue, when another queue gets a request? Have we considered just making the request queue a priority queue? 4. Related to 3, currently we have 2 metrics NetworkProcessorAvgIdlePercent and RequestHandlerAvgIdlePercent that measure the utilization of the network and the request handler thread pools. They are computed by measuring the amount of time waiting on the request queue. Will these 2 metrics be extended to support 2 request queues. Jun On Mon, Jun 18, 2018 at 1:04 PM, Lucas Wang <lucasatu...@gmail.com> wrote: > Hi All, > > I've addressed a couple of comments in the discussion thread for KIP-291, > and > got no objections after making the changes. Therefore I would like to start > the voting thread. > > KIP: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-291% > 3A+Have+separate+queues+for+control+requests+and+data+requests > > Thanks for your time! > Lucas >
