[
https://issues.apache.org/jira/browse/KAFKA-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224588#comment-15224588
]
Jason Gustafson commented on KAFKA-3491:
----------------------------------------
[~guozhang] That's what I was thinking initially, but then I thought that it
might be simpler to have it reset to the last committed offsets. I guess that
would be more of a reset() then a rewind(). In this case, for autocommit
behavior on close(), rewinding to the position on the previous poll() would be
more optimal since some records may have been successfully processed since the
last commit. But obviously it would require some additional state in the
consumer. Not sure if there are any other downsides.
> Issue with consumer close() in finally block with 'enable.auto.commit=true'
> ---------------------------------------------------------------------------
>
> Key: KAFKA-3491
> URL: https://issues.apache.org/jira/browse/KAFKA-3491
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Affects Versions: 0.9.0.0, 0.9.0.1
> Reporter: dan norwood
> Assignee: Jason Gustafson
> Priority: Minor
>
> imagine you have a run loop that looks like the following:
> {code:java}
> public void run() {
> try {
> consumer.subscribe(topics);
> while (true) {
> ConsumerRecords<K, V> records = consumer.poll(Long.MAX_VALUE);
> records.forEach(record -> process(record));
> }
> } catch (WakeupException e) {
> // ignore, we're closing
> } catch (Exception e) {
> log.error("Unexpected error", e);
> } finally {
> consumer.close();
> }
> }
> {code}
> if you run this with 'enable.auto.commit=true' and throw an exception in the
> 'process()' method you will still try to commit all the read, but
> unprocessed, offsets in the most recent batch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
