IGNITE-19960 Backport 1.3.10 release form the JRaft #2321
Conversation
…n blocking or non-blocking mode, and improve disruptor usage
This reverts commit 1f10b36.
| event.expectedTerm = task.getExpectedTerm(); | ||
| }; | ||
| switch (this.options.getApplyTaskMode()) { | ||
| case Blocking: |
There was a problem hiding this comment.
I'm not sure if a blocking mode has any use for us. Probably shouldn't be ported at all.
@alievmirza Do you know a single use case ?
There was a problem hiding this comment.
For example, it could help us to not fail with overload exception in scenarios like this https://issues.apache.org/jira/browse/IGNITE-19419
Also in the current implementation after overload of disk queue in LogManagerImpl and overload of FSMCallerImpl they enter erroneous state that is never reset, which makes impossible the further work of the component. It was fixed also
There was a problem hiding this comment.
It is forbidden to use blocking code in Ignite worker threads. The patch adds retries on a busy state, this should be enough. It seems a blocking mode will never be used.
2 participants
https://issues.apache.org/jira/browse/IGNITE-19960