To me, the validation you mentioned is not user friendly, assuming the values of linger.ms, request.timeout.ms, retry.backoff.ms are from cluster running previous release of Kafka.
For fresh installation, the validation is fine. On Mon, Sep 11, 2017 at 2:50 PM, Sumant Tambe <suta...@gmail.com> wrote: > @Ted, We throw a ConfigException when user-configured values of linger.ms, > request.timeout.ms, retry.backoff.ms add up to more than > delivery.timeout.ms > . The kip mentions this in the Validation section. > > On 11 September 2017 at 14:31, Ted Yu <yuzhih...@gmail.com> wrote: > > > bq. larger than default (linger.ms + request.timeout.ms + > retry.backoff.ms > > ) > > > > I was not referring to the sum of default values for the above > parameters. > > I was referring to the sum of user configured values for these parameters > > (since we don't know whether that sum is higher than 120 seconds or not) > . > > > > On Mon, Sep 11, 2017 at 10:06 AM, Sumant Tambe <suta...@gmail.com> > wrote: > > > > > @Jun, Until we make idempotent producer the default (kip-185), this kip > > is > > > sensitive to retries. I.e., we expire batches either > delivery.timeout.ms > > > passes or all retries are exhausted, whichever comes first. In cases > > where > > > retries exhaust first due to linger.ms + retries * (request.timeout.ms > + > > > retry.backoff.ms) being much smaller than delivery.timeout.ms, > multiple > > > failed requests (due to pipelining) will cause batches to expire > > > out-of-order. Right? > > > > > > @Ted, The idea is to have the default value of delivery.timeout.ms=120 > > > sec, > > > which is much larger than default (linger.ms + request.timeout.ms + > > > retry.backoff.ms). If a user configures them incorrectly, report a > > > ConfigException. > > > > > > > > > On 11 September 2017 at 09:11, Jun Rao <j...@confluent.io> wrote: > > > > > > > Hi, Sumant, > > > > > > > > Thanks for the KIP. +1. > > > > > > > > Just a minor clarification. The KIP says "Batches expire in order > > > > when max.in.flight.request.per.connection==1". Is that true? It > seems > > > that > > > > even with max.in.flight.request.per.connection > 1, batches should > > still > > > > expire in order. > > > > > > > > Jun > > > > > > > > On Sat, Sep 9, 2017 at 6:15 PM, Ted Yu <yuzhih...@gmail.com> wrote: > > > > > > > > > +1 for the KIP. > > > > > > > > > > For delivery.timeout.ms , since it should be >= linger.ms + > > > > > request.timeout.ms + retry.backoff.ms , it seems the default value > > > > should > > > > > be max(120 seconds, linger.ms + request.timeout.ms + > > retry.backoff.ms > > > ). > > > > > > > > > > Cheers > > > > > > > > > > On Fri, Sep 8, 2017 at 2:04 AM, Ismael Juma <ism...@juma.me.uk> > > wrote: > > > > > > > > > > > Thanks for the KIP. +1 (binding) from me. Just a minor > suggestion, > > I > > > > > would > > > > > > mention the following under "Public Interfaces": > > > > > > > > > > > > Default value of delivery.timeout.ms = 120 seconds > > > > > > Default value of retries will be changed to MAX_INT > > > > > > request.timeout.ms – current meaning, but messages are not > expired > > > > after > > > > > > this time. I.e., request.timeout.ms is no longer relevant for > > batch > > > > > > expiry. > > > > > > > > > > > > The compatibility impact of such changes can remain in the > > > > compatibility > > > > > > section. Also, I agree about keeping your "reordering" text > > although > > > it > > > > > > seems like the wiki wasn't updated to match what you posted in > the > > > > > > discussion thread. > > > > > > > > > > > > Ismael > > > > > > > > > > > > On Fri, Sep 8, 2017 at 6:06 AM, Sumant Tambe <suta...@gmail.com> > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I would like to open the vote for KIP-91: > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-91+ > > > > > > > Provide+Intuitive+User+Timeouts+in+The+Producer > > > > > > > > > > > > > > Thank you all for your input on the kip so far. > > > > > > > > > > > > > > Regards, > > > > > > > Sumant > > > > > > > > > > > > > > > > > > > > > > > > > > > >
