[
https://issues.apache.org/jira/browse/KAFKA-17064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862478#comment-17862478
]
PoAn Yang commented on KAFKA-17064:
-----------------------------------
Hi [~lianetm], in KAFKA-17017, we call `subscriptions#unsubscribe` if
`groupMetadata` is not present in `AsyncKafkaConsumer`. Do you think we should
also use event to trigger background thread to handle it? Thank you. cc
[~chia7712].
> New consumer assign should update assignment in background thread
> -----------------------------------------------------------------
>
> Key: KAFKA-17064
> URL: https://issues.apache.org/jira/browse/KAFKA-17064
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 3.8.0
> Reporter: Lianet Magrans
> Priority: Major
> Labels: consumer-threading-refactor, kip-848-client-support
> Fix For: 3.9.0
>
>
> With the new async consumer, the subscriptionState object is shared between
> the app thread and the background thread, but in principle all updates to the
> assignment should happen in the background thread, to avoid race conditions.
> Note that it's in the background where most updates to the assignment happen,
> as result of app event processing like unsubscribe, reconciliations, etc.).
> We've faced such races in places like unsubscribe and close, fixed by
> ensuring that all assignment updates happen in the background, and this also
> needs to be reviewed for the consumer.assign. The current implementation
> triggers an AssignmentChange event that is processed in the background, but
> that event is not really changing the assignment. It only commits offsets,
> and the assignment is updated in the app thread by calling
> subscriptionState.assignFromUser
> We should consider moving the assignment update to the background thread, as
> part of the AssignmentChangeEvent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
