You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Colin McCabe <cm...@apache.org> on 2017/01/21 00:19:21 UTC
[VOTE] KIP-74: Add FetchResponse size limit in bytes
Hi all,
While looking at some code related to KIP-74, I noticed a slight
discrepancy between the text on the wiki and the implementation. The
wiki says that "If max_bytes is Int.MAX_INT, new request behaves exactly
like old one." This would mean that if there was a single message that
was larger than the maximum bytes per partition, zero messages would be
returned, and clients would throw MessageSizeTooLargeException.
However, the code does not implement this. Instead, it implements the
"new" behavior where the client always gets at least one message.
The new behavior seems to be more desirable, since clients do not "get
stuck" on messages that are too big. I propose that we edit the wiki to
reflect the implemented behavior by deleting the references to special
behavior when max_bytes is MAX_INT.
cheers,
Colin
Re: [VOTE] KIP-74: Add FetchResponse size limit in bytes
Posted by Colin McCabe <cm...@apache.org>.
Thanks, all. I edited the wiki to reflect the implemented behavior by
dropping references to special behavior when max_bytes was INT_MAX.
cheers,
Colin
On Sat, Jan 21, 2017, at 09:44, radai wrote:
> +1
>
> On Fri, Jan 20, 2017 at 9:51 PM, Apurva Mehta <ap...@confluent.io>
> wrote:
>
> > +1
> >
> > On Fri, Jan 20, 2017 at 5:19 PM, Jason Gustafson <ja...@confluent.io>
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Jan 20, 2017 at 4:51 PM, Ismael Juma <is...@juma.me.uk> wrote:
> > >
> > > > Good catch, Colin. +1 to editing the wiki to match the desired
> > behaviour
> > > > and what was implemented in 0.10.1.
> > > >
> > > > Ismael
> > > >
> > > > On Sat, Jan 21, 2017 at 12:19 AM, Colin McCabe <cm...@apache.org>
> > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > While looking at some code related to KIP-74, I noticed a slight
> > > > > discrepancy between the text on the wiki and the implementation. The
> > > > > wiki says that "If max_bytes is Int.MAX_INT, new request behaves
> > > exactly
> > > > > like old one." This would mean that if there was a single message
> > that
> > > > > was larger than the maximum bytes per partition, zero messages would
> > be
> > > > > returned, and clients would throw MessageSizeTooLargeException.
> > > > > However, the code does not implement this. Instead, it implements
> > the
> > > > > "new" behavior where the client always gets at least one message.
> > > > >
> > > > > The new behavior seems to be more desirable, since clients do not
> > "get
> > > > > stuck" on messages that are too big. I propose that we edit the wiki
> > > to
> > > > > reflect the implemented behavior by deleting the references to
> > special
> > > > > behavior when max_bytes is MAX_INT.
> > > > >
> > > > > cheers,
> > > > > Colin
> > > > >
> > > >
> > >
> >
Re: [VOTE] KIP-74: Add FetchResponse size limit in bytes
Posted by radai <ra...@gmail.com>.
+1
On Fri, Jan 20, 2017 at 9:51 PM, Apurva Mehta <ap...@confluent.io> wrote:
> +1
>
> On Fri, Jan 20, 2017 at 5:19 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > +1
> >
> > On Fri, Jan 20, 2017 at 4:51 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > Good catch, Colin. +1 to editing the wiki to match the desired
> behaviour
> > > and what was implemented in 0.10.1.
> > >
> > > Ismael
> > >
> > > On Sat, Jan 21, 2017 at 12:19 AM, Colin McCabe <cm...@apache.org>
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > While looking at some code related to KIP-74, I noticed a slight
> > > > discrepancy between the text on the wiki and the implementation. The
> > > > wiki says that "If max_bytes is Int.MAX_INT, new request behaves
> > exactly
> > > > like old one." This would mean that if there was a single message
> that
> > > > was larger than the maximum bytes per partition, zero messages would
> be
> > > > returned, and clients would throw MessageSizeTooLargeException.
> > > > However, the code does not implement this. Instead, it implements
> the
> > > > "new" behavior where the client always gets at least one message.
> > > >
> > > > The new behavior seems to be more desirable, since clients do not
> "get
> > > > stuck" on messages that are too big. I propose that we edit the wiki
> > to
> > > > reflect the implemented behavior by deleting the references to
> special
> > > > behavior when max_bytes is MAX_INT.
> > > >
> > > > cheers,
> > > > Colin
> > > >
> > >
> >
>
Re: [VOTE] KIP-74: Add FetchResponse size limit in bytes
Posted by Apurva Mehta <ap...@confluent.io>.
+1
On Fri, Jan 20, 2017 at 5:19 PM, Jason Gustafson <ja...@confluent.io> wrote:
> +1
>
> On Fri, Jan 20, 2017 at 4:51 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > Good catch, Colin. +1 to editing the wiki to match the desired behaviour
> > and what was implemented in 0.10.1.
> >
> > Ismael
> >
> > On Sat, Jan 21, 2017 at 12:19 AM, Colin McCabe <cm...@apache.org>
> wrote:
> >
> > > Hi all,
> > >
> > > While looking at some code related to KIP-74, I noticed a slight
> > > discrepancy between the text on the wiki and the implementation. The
> > > wiki says that "If max_bytes is Int.MAX_INT, new request behaves
> exactly
> > > like old one." This would mean that if there was a single message that
> > > was larger than the maximum bytes per partition, zero messages would be
> > > returned, and clients would throw MessageSizeTooLargeException.
> > > However, the code does not implement this. Instead, it implements the
> > > "new" behavior where the client always gets at least one message.
> > >
> > > The new behavior seems to be more desirable, since clients do not "get
> > > stuck" on messages that are too big. I propose that we edit the wiki
> to
> > > reflect the implemented behavior by deleting the references to special
> > > behavior when max_bytes is MAX_INT.
> > >
> > > cheers,
> > > Colin
> > >
> >
>
Re: [VOTE] KIP-74: Add FetchResponse size limit in bytes
Posted by Jason Gustafson <ja...@confluent.io>.
+1
On Fri, Jan 20, 2017 at 4:51 PM, Ismael Juma <is...@juma.me.uk> wrote:
> Good catch, Colin. +1 to editing the wiki to match the desired behaviour
> and what was implemented in 0.10.1.
>
> Ismael
>
> On Sat, Jan 21, 2017 at 12:19 AM, Colin McCabe <cm...@apache.org> wrote:
>
> > Hi all,
> >
> > While looking at some code related to KIP-74, I noticed a slight
> > discrepancy between the text on the wiki and the implementation. The
> > wiki says that "If max_bytes is Int.MAX_INT, new request behaves exactly
> > like old one." This would mean that if there was a single message that
> > was larger than the maximum bytes per partition, zero messages would be
> > returned, and clients would throw MessageSizeTooLargeException.
> > However, the code does not implement this. Instead, it implements the
> > "new" behavior where the client always gets at least one message.
> >
> > The new behavior seems to be more desirable, since clients do not "get
> > stuck" on messages that are too big. I propose that we edit the wiki to
> > reflect the implemented behavior by deleting the references to special
> > behavior when max_bytes is MAX_INT.
> >
> > cheers,
> > Colin
> >
>
Re: [VOTE] KIP-74: Add FetchResponse size limit in bytes
Posted by Ismael Juma <is...@juma.me.uk>.
Good catch, Colin. +1 to editing the wiki to match the desired behaviour
and what was implemented in 0.10.1.
Ismael
On Sat, Jan 21, 2017 at 12:19 AM, Colin McCabe <cm...@apache.org> wrote:
> Hi all,
>
> While looking at some code related to KIP-74, I noticed a slight
> discrepancy between the text on the wiki and the implementation. The
> wiki says that "If max_bytes is Int.MAX_INT, new request behaves exactly
> like old one." This would mean that if there was a single message that
> was larger than the maximum bytes per partition, zero messages would be
> returned, and clients would throw MessageSizeTooLargeException.
> However, the code does not implement this. Instead, it implements the
> "new" behavior where the client always gets at least one message.
>
> The new behavior seems to be more desirable, since clients do not "get
> stuck" on messages that are too big. I propose that we edit the wiki to
> reflect the implemented behavior by deleting the references to special
> behavior when max_bytes is MAX_INT.
>
> cheers,
> Colin
>