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 >
