[
https://issues.apache.org/jira/browse/KAFKA-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224555#comment-15224555
]
Ewen Cheslack-Postava commented on KAFKA-3491:
----------------------------------------------
Yeah, `rewind` makes sense -- it's more general than the `close(boolean)`.
Technically it'd just be a convenience wrapper around `seek` that avoids having
to track the offsets from the last batch, right? If we go that route, I want to
make sure the other use cases are well fleshed out. If you take enough care to
handle unresponsive downstream systems properly, is this going to be a
significant simplification? Is it even what you'll want to do? At some point
it'll make sense to actually track the offsets in the application and rewind to
the exact point things started failing since half the batch may have completed
successfully.
> 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)
