The proposal makes sense to me. I like that the plan to support both limits simultaneously:
queued.max.requests is supported in addition queued.max.bytes (both > respected at the same time). In this case a default value of > queued.max.bytes = -1 would maintain backwards compatible behavior. Especially since ByteBoundedBlockingQueue already supports a limit on byte and element count. I actually don't mind the property naming of queued.max.*. I am not sure if the added clarity of requestQueue.max.* is worth the migration. On Fri, Aug 5, 2016 at 9:34 AM, Tom Crayford <tcrayf...@heroku.com> wrote: > This makes good sense to me, and seems to have very low amounts of downside > with large amounts of upside. +1 > > On Thursday, 4 August 2016, radai <radai.rosenbl...@gmail.com> wrote: > > > Hello, > > > > I'd like to initiate a discussion about > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > 72%3A+Allow+Sizing+Incoming+Request+Queue+in+Bytes > > > > The goal of the KIP is to allow configuring a bound on the capacity (as > in > > bytes of memory used) of the incoming request queue, in addition to the > > current bound on the number of messages. > > > > This comes after several incidents at Linkedin where a sudden "spike" of > > large message batches caused an out of memory exception. > > > > Thank you, > > > > Radai > > > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
