[ 
https://issues.apache.org/jira/browse/KAFKA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821910#comment-17821910
 ] 

Kirk True commented on KAFKA-16290:
-----------------------------------

There are many {{Consumer}} APIs in which the {{AsyncKafkaConsumer}} references 
the {{SubscriptionState}}.

h3. State mutation:
 
* {{assign(Collection<TopicPartition>)}}
* {{close()}}
* {{close(Duration)}}
* {{currentLag(TopicPartition)}}
* {{pause(Collection<TopicPartition>)}}
* {{poll(Duration)}}
* {{position(TopicPartition)}}
* {{position(TopicPartition, Duration)}}
* {{resume(Collection<TopicPartition>)}}
* {{seek(TopicPartition, long)}}
* {{seek(TopicPartition, OffsetAndMetadata)}}
* {{seekToBeginning(Collection<TopicPartition>)}}
* {{subscribe(Collection<String>)}}
* {{subscribe(Collection<String>, ConsumerRebalanceListener)}}
* {{subscribe(Pattern)}}
* {{subscribe(Pattern, ConsumerRebalanceListener)}}
* {{unsubscribe()}}

h3. State lookup:
 
* {{assignment()}}
* {{commitAsync(OffsetCommitCallback)}}
* {{commitSync(Duration)}}
* {{paused()}}
* {{subscription()}}


> 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
>            Assignee: Kirk True
>            Priority: Critical
>              Labels: kip-848
>             Fix For: 3.8.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)

Reply via email to