Does this mean that if the client have retry > 0 and max.in.flight.requests.per.connection > 1, then even if the topic only have one partition, there’s still no guarantee of the ordering?
Thanks, Jun > On Apr 30, 2017, at 7:57 AM, Hans Jespersen <h...@confluent.io> wrote: > > There is a parameter that controls this behavior called max.in. > flight.requests.per.connection > > If you set max.in. flight.requests.per.connection = 1 then the producer waits > until previous produce requests returns a response before sending the next > one (or retrying). The retries parameter controller the number of times to > attempt to produce a batch after a failure. > > If flight.requests.per.connection = 1 and retries is get to the maximum then > ordering is guaranteed. > > If there is a timeout then the producer library would try again and again to > produce the message and will not skip over to try and produce the next > message. > > If you set flight.requests.per.connection > 1 (I think the default is 5) then > you can get a commit log with messages out of order wrt the original > published order (because retries are done in parallel rather then in series) > > -hans > > > >> On Apr 30, 2017, at 3:13 AM, Petr Novak <oss.mli...@gmail.com> wrote: >> >> Hello, >> >> Does Kafka producer waits till previous batch returns response before >> sending next one? Do I assume correctly that it does not when retries can >> change ordering? >> >> >> >> Hence batches delay is introduced only by producer internal send loop time >> and linger? >> >> >> >> If a timeout would be localized only to a single batch send request for some >> reason, does it affect the next batch (assuming this batch can go through >> successfully)? >> >> >> >> Many thanks, >> >> Petr >>
