The consumer is single-threaded, so we only trigger commits in the call to poll(). As long as you consume all the records returned from each poll call, the committed offset will never get ahead of the consumed offset, and you'll have at-lest-once delivery. Note that the implication is that " auto.commit.interval.ms" is not strictly followed unless each iteration of the loop takes less time than the configured commit interval.
-Jason On Thu, Feb 18, 2016 at 2:21 PM, Avi Flax <a...@aviflax.com> wrote: > On Thu, Feb 18, 2016 at 4:26 PM, Jay Kreps <j...@confluent.io> wrote: > > The default semantics of the new consumer with auto commit are > > at-least-once-delivery. Basically during the poll() call the commit will > be > > triggered and will commit the offset for the messages consumed during the > > previous poll call. This is an advantage over the older scala consumer > > where the consumer did not have this guarantee because the commit > happened > > asynchronously in a separate thread and hence could end up preceeding or > > succeeding the actual processing of data. > > Sorry, I just realized I have one follow-up question on this… if this > is the case, then why does the new consumer have the config property > `auto.commit.interval.ms`? The approach of committing automatically > after an interval seems to me to be at odds with the approach of > committing after each call to poll(). What am I missing here? > > Thanks! > Avi >
