[jira] [Commented] (KAFKA-12711) Add a back off option to replace thread

["Guozhang Wang (Jira)" <ji...@apache.org>]

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

Guozhang Wang commented on KAFKA-12711:
---------------------------------------

I'm +1 for this feature. Generally speaking, we should make any exceptional handler implementation to be instantaneous with a decision returned from the thread, if the decision is a "delayed operation" then KS could schedule that to happen internally, instead letting the impl to get on hold of that throwing thread.

To cope with that rule of thumb, maybe we can adjust our FSM as well such that, before the exception handler is triggered, the Streams instance state transit to a new state, like "pending", and only transit back to the corresponding new state when exception handler returns. We can also consider piggy-back on the "pending error" state, but that would mean that this state do not only transit to "error" but can also transit back to normal states. Personally I'm feeling okay to piggy-back on pending error so that we do not introduce a new state.

> Add a back off option to replace thread
> ---------------------------------------
>
>                 Key: KAFKA-12711
>                 URL: https://issues.apache.org/jira/browse/KAFKA-12711
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Walker Carlson
>            Priority: Major
>              Labels: needs-kip
>
> There should be a native option to set a back off period when replacing a thread from the stream uncaught exception handler.
>  
> Either there should be a config and a user chosen strategy or a value you can set in the handler that causes a delay in creating the new thread.
>  
> It might also be achieved by making the option to add a thread in N seconds then using that in the replace thread option 



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