You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Walker Carlson (Jira)" <ji...@apache.org> on 2020/12/09 02:43:00 UTC

[jira] [Commented] (KAFKA-10555) Improve client state machine

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

Walker Carlson commented on KAFKA-10555:
----------------------------------------

[https://cwiki.apache.org/confluence/x/lCvZCQ] I have made KIP that clarifies the definition of ERROR state.

I think if we want to add NOT_POLLING or the like we should make that a separate issue as it does not seem necessary right now. 

> Improve client state machine
> ----------------------------
>
>                 Key: KAFKA-10555
>                 URL: https://issues.apache.org/jira/browse/KAFKA-10555
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Matthias J. Sax
>            Assignee: Walker Carlson
>            Priority: Major
>              Labels: needs-kip
>
> The KafkaStreams client exposes its state to the user for monitoring purpose (ie, RUNNING, REBALANCING etc). The state of the client depends on the state(s) of the internal StreamThreads that have their own states.
> Furthermore, the client state has impact on what the user can do with the client. For example, active task can only be queried in RUNNING state and similar.
> With KIP-671 and KIP-663 we improved error handling capabilities and allow to add/remove stream thread dynamically. We allow adding/removing threads only in RUNNING and REBALANCING state. This puts us in a "weird" position, because if we enter ERROR state (ie, if the last thread dies), we cannot add new threads and longer. However, if we have multiple threads and one dies, we don't enter ERROR state and do allow to recover the thread.
> Before the KIPs the definition of ERROR state was clear, however, with both KIPs it seem that we should revisit its semantics.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)