[
https://issues.apache.org/jira/browse/KAFKA-20879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax updated KAFKA-20879:
------------------------------------
Summary: Consider to add a `SuspendReason` to
`StateRestoreListener#onRestoreSuspended` (was: Consider to add a
`SuspendReason` to `StateRestoreListener#onRestoreSupsended)
> Consider to add a `SuspendReason` to `StateRestoreListener#onRestoreSuspended`
> ------------------------------------------------------------------------------
>
> Key: KAFKA-20879
> URL: https://issues.apache.org/jira/browse/KAFKA-20879
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Matthias J. Sax
> Priority: Minor
> Labels: needs-kip
>
> ## Description
> When an active task's restoration is interrupted,
> `StateRestoreListener.onRestoreSuspended` is called, but it does not say why.
> There are three reasons it can happen, and they are indistinguishable to the
> application:
> - the task was assigned to another instance,
> - the task was demoted to a standby task on this instance,
> - this instance is shutting down.
> The sibling callback on the other listener does distinguish them.
> `StandbyUpdateListener.onUpdateSuspended` receives a `SuspendReason`. An
> application that follows both listeners to track where its tasks live
> therefore gets a cause for a replica that stops updating, but none for an
> active task that stops restoring.
> ### Scope: only a task that is still restoring
> This is limited to an active task that had **not** finished restoring. If a
> task is RUNNING and there is no restoration in progress, there is nothing for
> a restore listener to report, and the resulting standby task is reported
> through `StandbyUpdateListener.onUpdateStart` as usual. So overall it's a
> rare case, but still worth to address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
