[
https://issues.apache.org/jira/browse/KAFKA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873962#comment-17873962
]
Lianet Magrans commented on KAFKA-16290:
----------------------------------------
This issue is being fixed by several other jiras (I liked them all). Basically
we've been doing the changes per api call, to ensure that the subscription
state is only updated in the background. Subscription state changes are now
propagated from the app thread to the background via queues (based on the app
events and the app event queue). I'll mark this Jira for investigation as
closed, and we can follow-up on the liked jiras.
> Investigate propagating subscription state updates via queues
> -------------------------------------------------------------
>
> Key: KAFKA-16290
> URL: https://issues.apache.org/jira/browse/KAFKA-16290
> Project: Kafka
> Issue Type: Task
> Components: clients, consumer
> Reporter: Lucas Brutschy
> Priority: Critical
> Labels: consumer-threading-refactor, kip-848,
> kip-848-client-support
> Fix For: 4.0.0
>
>
> We are mostly using the queues for interaction between application thread and
> background thread, but the subscription object is shared between the threads,
> and it is updated directly without going through the queues.
> The way we allow updates to the subscription state from both threads is
> definitely not right, and will bring trouble. Places like the assign() is
> probably the most obvious, where we send an event to the background to
> commit, but then update the subscription in the foreground right away.
> It seems sensible to aim for having all updates to the subscription state in
> the background, triggered from the app thread via events (and I think we
> already have related events for all updates, just that the subscription state
> was left out in the app thread).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
