Hi all! I declare the vote as passed. :) Thank you all for valuable input - really appreciate it. I’ll update KIP soon. I believe it should be ready early next week.
Andrey. > On 23 Aug 2016, at 12:43, Ismael Juma <ism...@juma.me.uk> wrote: > > Thanks Andrey. It has been 7 days since the vote started and there are 3 > binding +1 votes (and 3 non-binding +1 votes), so you are free to declare > the vote as passed whenever you're ready. :) > > Will you be able to update the PR to match the KIP soon? > > Thanks, > Ismael > > On Mon, Aug 22, 2016 at 12:01 PM, Andrey L. Neporada < > anepor...@yandex-team.ru> wrote: > >> Thanks. >> Request parameter renamed: response_max_bytes -> max_bytes. >> >> Andrey. >> >>> On 19 Aug 2016, at 16:52, Ismael Juma <ism...@juma.me.uk> wrote: >>> >>> Thanks for the KIP. +1 (binding) with the following suggestion: >>> >>> Fetch Request (Version: 3) => replica_id max_wait_time min_bytes >>> response_max_bytes [topics] >>> replica_id => INT32 >>> max_wait_time => INT32 >>> min_bytes => INT32 >>> response_max_bytes => INT32 >>> topics => topic [partitions] >>> topic => STRING >>> partitions => partition fetch_offset max_bytes >>> partition => INT32 >>> fetch_offset => INT64 >>> max_bytes => INT32 >>> >>> >>> I think "response_max_bytes" should be called "max_bytes". That way >>> it's consistent with "min_bytes" (which is also a response-level >>> property). >>> >>> I understand the desire to differentiate it from the "max_bytes" >>> passed with each partition, but I think it's fine to rely on the >>> context (containing struct) for that. >>> >>> >>> Ismael >>> >>> >>> >>> On Fri, Aug 19, 2016 at 1:47 PM, Tom Crayford <tcrayf...@heroku.com> >> wrote: >>> >>>> +1 (non binding) >>>> >>>> On Fri, Aug 19, 2016 at 6:20 AM, Manikumar Reddy < >>>> manikumar.re...@gmail.com> >>>> wrote: >>>> >>>>> +1 (non-binding) >>>>> >>>>> This feature help us control memory footprint and allows consumer to >>>>> progress on fetching large messages. >>>>> >>>>> On Fri, Aug 19, 2016 at 10:32 AM, Gwen Shapira <g...@confluent.io> >>>> wrote: >>>>> >>>>>> +1 (binding) >>>>>> >>>>>> On Thu, Aug 18, 2016 at 1:47 PM, Andrey L. Neporada >>>>>> <anepor...@yandex-team.ru> wrote: >>>>>>> Hi all! >>>>>>> I’ve modified KIP-74 a little bit (as requested by Jason Gustafson & >>>>> Jun >>>>>> Rao): >>>>>>> 1) provided more detailed explanation on memory usage (no functional >>>>>> changes) >>>>>>> 2) renamed “fetch.response.max.bytes” -> “fetch.max.bytes” >>>>>>> >>>>>>> Let’s continue voting in this thread. >>>>>>> >>>>>>> Thanks! >>>>>>> Andrey. >>>>>>> >>>>>>>> On 17 Aug 2016, at 00:02, Jun Rao <j...@confluent.io> wrote: >>>>>>>> >>>>>>>> Andrey, >>>>>>>> >>>>>>>> Thanks for the KIP. +1 >>>>>>>> >>>>>>>> Jun >>>>>>>> >>>>>>>> On Tue, Aug 16, 2016 at 1:32 PM, Andrey L. Neporada < >>>>>>>> anepor...@yandex-team.ru> wrote: >>>>>>>> >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> I would like to initiate the voting process for KIP-74: >>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP- >>>>>>>>> 74%3A+Add+Fetch+Response+Size+Limit+in+Bytes >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Andrey. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Gwen Shapira >>>>>> Product Manager | Confluent >>>>>> 650.450.2760 | @gwenshap >>>>>> Follow us: Twitter | blog >>>>>> >>>>> >>>> >> >>
