[
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)
