[GitHub] [kafka] mjsax commented on pull request #13523: [DO NOT MERGE] MINOR: Follow-up on failing streams test

["mjsax (via GitHub)" <gi...@apache.org>]

mjsax commented on PR #13523:
URL: https://github.com/apache/kafka/pull/13523#issuecomment-1500590801

   We did not introduce a `PAUSED` state, because of named topologies (which are still internal, but if we make it public would "break" `PAUSED` state). So when we are pausing, state would stay the same as it was when `PAUSE` is called, so it could either be `REBALANCING` or `RUNNING`. (Not ideal, but this is how it works right now.)
   
   >  Is it the case that until the instance state transitions to RUNNING, no active tasks can process data?
   
   No. The state is rather a reflection of what the runtime is doing, not the other way around.
   
   When/if we change the behavior in the future, and let the main thread process active task, while the restore thread is still restoring other active tasks, we need to reconsider what state we want to expose. Neither `RUNNING` nor `REBALANCING` (ie, restoring) would reflect that the runtime is doing any longer. But this is a question for a future KIP I guess, and not related to this PR.
   
   I also prefer option (2) -- seems to be cleanest. Right now we have a binary `RUNNING` or `REBALANCING` (ie, restoring), and given their either the restore thread does active restoring or the main thread does active processing, it seems best to stay in `REBALANCING` state if the restore thread is not done when we pause.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org