alievmirza commented on code in PR #2321:
URL: https://github.com/apache/ignite-3/pull/2321#discussion_r1275959917


##########
modules/raft/src/main/java/org/apache/ignite/raft/jraft/core/NodeImpl.java:
##########
@@ -1857,36 +1856,30 @@ public void apply(final Task task) {
 
         final LogEntry entry = new LogEntry();
         entry.setData(task.getData());
-        int retryTimes = 0;
-        try {
-            final EventTranslator<LogEntryAndClosure> translator = (event, 
sequence) -> {
-                event.reset();
-                event.nodeId = getNodeId();
-                event.done = task.getDone();
-                event.entry = entry;
-                event.expectedTerm = task.getExpectedTerm();
-            };
-            while (true) {
-                if (this.applyQueue.tryPublishEvent(translator)) {
-                    break;
-                }
-                else {
-                    retryTimes++;
-                    if (retryTimes > MAX_APPLY_RETRY_TIMES) {
-                        
Utils.runClosureInThread(this.getOptions().getCommonExecutor(), task.getDone(),
-                            new Status(RaftError.EBUSY, "Node is busy, has too 
many tasks."));
-                        LOG.warn("Node {} applyQueue is overload.", 
getNodeId());
-                        this.metrics.recordTimes("apply-task-overload-times", 
1);
-                        return;
+
+        final EventTranslator<LogEntryAndClosure> translator = (event, 
sequence) -> {
+            event.reset();
+            event.nodeId = getNodeId();
+            event.done = task.getDone();
+            event.entry = entry;
+            event.expectedTerm = task.getExpectedTerm();
+        };
+        switch (this.options.getApplyTaskMode()) {
+            case Blocking:

Review 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 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to