RATIS-2505. Improve RATIS-2387 with direct synchronous append when compose disabled

[ss77892]

What changes were proposed in this pull request?

When appendEntriesComposeEnabled is disabled (set to false), the code now bypasses the appendLog() method entirely and invokes the append operation directly on the current thread. This change eliminates the unnecessary async hop that remained in RATIS-2387. Instead of creating a completed future and then using thenComposeAsync() to schedule the append on the executor, the append now happens immediately on the calling thread.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/RATIS-2505

How was this patch tested?

Ozone cluster deployment with high volume write load.

[ss77892]

@szetszwo, you might find it interesting.

[szetszwo]

The change looks good. However, could you make it a one-line change?

+++ b/ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java
@@ -1682,7 +1682,7 @@ class RaftServerImpl implements RaftServer.Division,
     future.join();
     final CompletableFuture<Void> appendFuture = entries.isEmpty()? CompletableFuture.completedFuture(null)
         : appendLogTermIndices != null ? appendLogTermIndices.append(entries, this::appendLog)
-        : appendLog(entries);
+        : JavaUtils.allOf(state.getLog().append(entries));

     proto.getCommitInfosList().forEach(commitInfoCache::update);

[yandrey321]

can we cover these changes with unit tests?

[szetszwo]

This revert the code to pre- RATIS-2235. So, new unit tests probably are not needed.

[ss77892]

@szetszwo sure. I just thought that if/else is easier to understand.

[szetszwo]

+1 the change looks good.

[szetszwo]

... I just thought that if/else is easier to understand.

Different people have a different taste. If it is new code, it is fine either way. But for the existing code, let's just minimize the change.

[yandrey321]

This revert the code to pre- RATIS-2235. So, new unit tests probably are not needed.

its a second change for reverting behavior to pre-RATIS-2235, and we got regression for the previous attempt. so my concern is that unit tests did not catch the regression.

[szetszwo]

@yandrey321 , RATIS-2235 reported a problem "two appendEntries calls about the same time" and fixed it. Then, Ozone said that it was not a problem for them and wanted to make RATIS-2235 configurable.

Now, what unit tests are you suggesting? Trigger "two appendEntries calls about the same time" with RATIS-2235 disabled and hope that it won't fail?

Anyway, if you have any suggestion, I am happy to create new tests.

[yandrey321]

I'd add a test with running appendEntries() from multiple concurrent threads and check that at the end all entries are present.

[szetszwo]

... multiple concurrent threads and check that at the end all entries are present.

How would it be different from below?

• Trigger "two appendEntries calls about the same time" with RATIS-2235 disabled and hope that it won't fail?