[
https://issues.apache.org/jira/browse/KAFKA-20119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18056448#comment-18056448
]
Lianet Magrans commented on KAFKA-20119:
----------------------------------------
Agree with the difference as described and adding a clarification, makes total
sense. As for changing the behaviour, it could also make sense but I wonder if
we should think a bit more about it, 2 mains things come to mind:
* the different meanings of consumer.close ("I'm done doing my job on the
topics I have") vs consumer unsubscribe ("I'm no longer interested in handling
these topics"), so how should we expect to persist progress based on
auto-commits? (
* the "contract" of auto-commit (which is kind of loose with just a "periodic"
save, not more than that), so this would be kind of re-thinking it
Just food for thought, surely interesting to dig dipper, good point!
> Clarify that `Consumer#unsubscribe` does not trigger auto-commit
> ----------------------------------------------------------------
>
> Key: KAFKA-20119
> URL: https://issues.apache.org/jira/browse/KAFKA-20119
> Project: Kafka
> Issue Type: Improvement
> Reporter: Chia-Ping Tsai
> Assignee: TaiJuWu
> Priority: Minor
>
> I suggest adding a note to clarify that unsubscribe() does not guarantee a
> commit, which could lead to duplicate processing if offsets are not manually
> committed.
> {code:java}
> Note: Unlike close(), this method does not guarantee that pending offsets are
> committed before unsubscribing, even if enable.auto.commit is enabled. To
> avoid duplicate processing upon re-joining, it is recommended to explicitly
> call {@link #commitSync()} before invoking this method
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
