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 <apu...@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 <ism...@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 <cmcc...@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 > > > > > > > > > > > > > >
