Yeah I didn't mean to imply that we committed after each poll, but rather that when it was time to commit, this would happen on the next poll call and hence only commit processed messages.
-Jay 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 >
