[
https://issues.apache.org/jira/browse/RATIS-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated RATIS-2196:
-------------------------------
Description:
Some of the StateMachine notification APIs are run sequentially in very
important parts of the code (e.g. StateMachineUpdater). This carries a few
risks:
* If the notification API implementation blocks, it might cause the
StateMachine performance to suffer (e.g. notifyLeaderReady might block
StateMachineUpdater)
* Exception thrown in this notification APIs might cause the whole
StateMachine to be down (e.g. NPE in notifyLeaderReady will cause
StateMachineUpdater to be terminated)
One idea is to make this notification API asynchronous. For example, by having
a specific ExecutorService to run the notifications, or just do a "fire and
forget" method.
One downside is that if the StateMachine implementation relies on the
sequential nature of the StateMachine notification API, it might not be wise to
make this asynchoronous.
We can discuss the expected semantics for the notification API and whether
making the notification API asynchronous going forward makes sense.
was:
Some of the StateMachine notification APIs are run sequentially in very
important parts of the code (e.g. StateMachineUpdater). This carries a few
risks:
* If the notification API implementation blocks, it might cause the
StateMachine performance to suffer (e.g. notifyLeaderReady might block
StateMachineUpdater)
* Exception thrown in this notification APIs might cause the whole
StateMachine to be down (e.g. NPE in notifyLeaderReady will cause
StateMachineUpdater to be terminated)
One idea is to make this notification API asynchronous. For example, by having
a specific ExecutorService to run the notifications, or just do a "fire and
forget" method.
One downside is that if the StateMachine implementation relies on the
sequential nature of the StateMachine notification API, it might not be wise to
make this asynchoronous.
We can discuss whether making the notification API asynchronous make sense.
> Make StateMachine notification API asynchronous
> -----------------------------------------------
>
> Key: RATIS-2196
> URL: https://issues.apache.org/jira/browse/RATIS-2196
> Project: Ratis
> Issue Type: Improvement
> Reporter: Ivan Andika
> Priority: Major
>
> Some of the StateMachine notification APIs are run sequentially in very
> important parts of the code (e.g. StateMachineUpdater). This carries a few
> risks:
> * If the notification API implementation blocks, it might cause the
> StateMachine performance to suffer (e.g. notifyLeaderReady might block
> StateMachineUpdater)
> * Exception thrown in this notification APIs might cause the whole
> StateMachine to be down (e.g. NPE in notifyLeaderReady will cause
> StateMachineUpdater to be terminated)
> One idea is to make this notification API asynchronous. For example, by
> having a specific ExecutorService to run the notifications, or just do a
> "fire and forget" method.
> One downside is that if the StateMachine implementation relies on the
> sequential nature of the StateMachine notification API, it might not be wise
> to make this asynchoronous.
> We can discuss the expected semantics for the notification API and whether
> making the notification API asynchronous going forward makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
