RATIS-1709 Support specify ThreadGroup for Daemon threads by jiacheliu3 · Pull Request #733 · apache/ratis

jiacheliu3 · 2022-09-03T09:49:41Z

What changes were proposed in this pull request?

Updates the RaftServer API so the application can pass in an ThreadGroup to control Ratis threads consistently with the application. The app can specify ThreadGroup.uncaughtException() to catch uncaught exceptions from ratis.
The most critical Daemon threads will be created with the app-specified ThreadGroup, so the application will decide what to do when RaftServer is seeing an unhandled error
Only the most important Daemon threads will have this ThreadGroup and others will not, so unimportant transient errors will stay inside Ratis abstraction

What is the link to the Apache JIRA

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

How was this patch tested?

(Please explain how this patch was tested. Ex: unit tests, manual tests)
(If this patch involves UI changes, please attach a screen-shot; otherwise, remove this)

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java

jiacheliu3 · 2022-09-03T10:57:51Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java

+  public void setError(Throwable t) {
+    throwable = t;
+    LOG.error("Server transitioning to EXCEPTION state due to", t);
+    // TODO(jiacheng): will the server keep serving or just die itself?


Sorry I'm new to Ratis code in general so not sure what's the recommended design. Will this be a good place for the server to exit, or it should check this state and exit somewhere else?

We should let the application decide. Therefore, we should pass an UncaughtExceptionHandler from the application.

This might be a larger question than this particular fix but, would an UncaughtExceptionHandler be too specific? I imagine the application prefers something like a pre-crash hook that's applied to all places where the RaftServer is going to crash or be set to EXCEPTION lifecycle state.

I'm good with just an UncaughtExceptionHandler for now of course because that's what my application needs.

jiacheliu3 · 2022-09-03T11:00:03Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

      try {
        getServerRpc().close();
      } catch(IOException ignored) {
+        // TODO(jiacheng): transition state to EXCEPTION here?


In the existing code I don't think we transition to EXCEPTION very often. In many places like this, we might wanna transition the state and expose the exception to the outside. And the Ratis user can just observe the RaftServer lifecycle and choose to restart the RaftServer or do whatever else.

When it is in CLOSING state, it must transit to CLOSED but won't transit to EXCEPTION. CLOSING must handle the exceptions, if there are any.

FYI this logic is gone tgt with the ErrorRecorded interface. I no longer have this default behavior in the RaftServerProxy because it now takes an uncaughtExceptionHandler from the application. Is that okay? @szetszwo

jiacheliu3 · 2022-09-03T11:08:44Z

ratis-server/src/main/java/org/apache/ratis/server/impl/LeaderElection.java

    Executor(Object name, int size) {
      Preconditions.assertTrue(size > 0);
+      // TODO(jiacheng): intentionally ignoring the server ref here? Why?
      executor = Executors.newFixedThreadPool(size, r -> new Daemon(r, name + "-" + count.incrementAndGet()));


Intentionally not passing the RaftServerImpl reference to the Daemon thread so a dead thread doesn't set the RaftServerImpl state to EXCEPTION. My intuition is that a failed prevote doesn't matter that much because it will be retried. Could someone confirm?

jiacheliu3 · 2022-09-03T11:13:50Z

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java

    this.setName(name);
  }
+
+  public Daemon(Runnable runnable, String name, ErrorRecorded server) {


I ignored Daemon threads created in JvmPauseMonitor and TimeoutScheduler because my intuition is even if they crash, the RaftServer can still live.

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java

jiacheliu3 · 2022-09-03T12:01:10Z

@codings-dan PTAL if the design meets expectation and pls feel free to add any reviewers to the discussion. If you are all okay with the idea and design, I will move on to add unit tests.

On unit tests, I'm honestly not sure what you would expect me to add. I mean, this PR adds UnexpectedExceptionHandlers then I guess I should add tests to trigger unhandled exceptions to each Daemon thread? Or just having one test on the Daemon thread class itself would be acceptable? I'm new to Ratis repo so I'd like to conform to how you normally test. Any advice is appreciated!

codings-dan · 2022-09-04T11:39:55Z

@jiacheliu3 Thanks for working on this, I will review the change recently @szetszwo Could you help take a look at this pull request?

szetszwo · 2022-09-05T01:17:58Z

@codings-dan , sure, will review this.

@jiacheliu3 , thanks a lot for working this! There were some failures in https://github.com/apache/ratis/actions/runs/2984287869 . Could you take a look?

jiacheliu3 · 2022-09-05T08:17:02Z

Is this one flaky? This UT passes on my local build.

Error:  Tests run: 16, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 42.736 s <<< FAILURE! - in org.apache.ratis.server.simulation.TestLeaderElectionWithSimulatedRpc
Error:  testRemoveListener(org.apache.ratis.server.simulation.TestLeaderElectionWithSimulatedRpc)  Time elapsed: 1.711 s  <<< ERROR!
java.lang.IllegalStateException: Found duplicated element s0|rpc:localhost:38565|admin:localhost:42183|client:localhost:37945|dataStream:localhost:42749|priority:0|startupRole:FOLLOWER in [s0|rpc:localhost:38565|admin:localhost:42183|client:localhost:37945|dataStream:localhost:42749|priority:0|startupRole:FOLLOWER, s2|rpc:localhost:40489|admin:localhost:40079|client:localhost:44937|dataStream:localhost:40043|priority:0|startupRole:FOLLOWER, s0|rpc:localhost:38565|admin:localhost:42183|client:localhost:37945|dataStream:localhost:42749|priority:0|startupRole:FOLLOWER]
	at org.apache.ratis.util.Preconditions.assertTrue(Preconditions.java:73)
	at org.apache.ratis.util.Preconditions.assertUnique(Preconditions.java:128)
	at org.apache.ratis.util.Preconditions.assertUnique(Preconditions.java:122)
	at org.apache.ratis.protocol.SetConfigurationRequest$Arguments.<init>(SetConfigurationRequest.java:59)
	at org.apache.ratis.protocol.SetConfigurationRequest$Arguments.<init>(SetConfigurationRequest.java:36)
	at org.apache.ratis.protocol.SetConfigurationRequest$Arguments$Builder.build(SetConfigurationRequest.java:144)
	at org.apache.ratis.client.api.AdminApi.setConfiguration(AdminApi.java:55)
	at org.apache.ratis.client.api.AdminApi.setConfiguration(AdminApi.java:40)
	at org.apache.ratis.server.impl.LeaderElectionTests.testRemoveListener(LeaderElectionTests.java:353)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:829)

codings-dan · 2022-09-05T08:28:08Z

Is this one flaky? This UT passes on my local build.

Error:  Tests run: 16, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 42.736 s <<< FAILURE! - in org.apache.ratis.server.simulation.TestLeaderElectionWithSimulatedRpc
Error:  testRemoveListener(org.apache.ratis.server.simulation.TestLeaderElectionWithSimulatedRpc)  Time elapsed: 1.711 s  <<< ERROR!
java.lang.IllegalStateException: Found duplicated element s0|rpc:localhost:38565|admin:localhost:42183|client:localhost:37945|dataStream:localhost:42749|priority:0|startupRole:FOLLOWER in [s0|rpc:localhost:38565|admin:localhost:42183|client:localhost:37945|dataStream:localhost:42749|priority:0|startupRole:FOLLOWER, s2|rpc:localhost:40489|admin:localhost:40079|client:localhost:44937|dataStream:localhost:40043|priority:0|startupRole:FOLLOWER, s0|rpc:localhost:38565|admin:localhost:42183|client:localhost:37945|dataStream:localhost:42749|priority:0|startupRole:FOLLOWER]
	at org.apache.ratis.util.Preconditions.assertTrue(Preconditions.java:73)
	at org.apache.ratis.util.Preconditions.assertUnique(Preconditions.java:128)
	at org.apache.ratis.util.Preconditions.assertUnique(Preconditions.java:122)
	at org.apache.ratis.protocol.SetConfigurationRequest$Arguments.<init>(SetConfigurationRequest.java:59)
	at org.apache.ratis.protocol.SetConfigurationRequest$Arguments.<init>(SetConfigurationRequest.java:36)
	at org.apache.ratis.protocol.SetConfigurationRequest$Arguments$Builder.build(SetConfigurationRequest.java:144)
	at org.apache.ratis.client.api.AdminApi.setConfiguration(AdminApi.java:55)
	at org.apache.ratis.client.api.AdminApi.setConfiguration(AdminApi.java:40)
	at org.apache.ratis.server.impl.LeaderElectionTests.testRemoveListener(LeaderElectionTests.java:353)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:829)

let me re-run the ci test

szetszwo

@jiacheliu3 , thanks again for working on this. It is better to pass an UncaughtExceptionHandler so that the application can decide what to do. Please see the comments inlined.

szetszwo · 2022-09-05T09:23:05Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

      try {
        getServerRpc().close();
      } catch(IOException ignored) {
+        // TODO(jiacheng): transition state to EXCEPTION here?


When it is in CLOSING state, it must transit to CLOSED but won't transit to EXCEPTION. CLOSING must handle the exceptions, if there are any.

szetszwo · 2022-09-05T09:29:46Z

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java

+  public static class Builder {
+    private final String name;
+    private Runnable runnable;
+    private ErrorRecorded statedServer;


Let's pass an UncaughtExceptionHandler instead of adding ErrorRecorded.

ratis-common/src/main/java/org/apache/ratis/util/TimeoutScheduler.java

ratis-common/src/main/java/org/apache/ratis/util/ErrorRecorded.java

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java

szetszwo · 2022-09-05T09:43:46Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java

+  public void setError(Throwable t) {
+    throwable = t;
+    LOG.error("Server transitioning to EXCEPTION state due to", t);
+    // TODO(jiacheng): will the server keep serving or just die itself?


We should let the application decide. Therefore, we should pass an UncaughtExceptionHandler from the application.

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java

jiacheliu3 · 2022-09-05T10:13:39Z

@szetszwo Thanks for the comments! What do you think about exposing the exception on the RaftServer? I come from Alluxio and we use Ratis RaftServer to manage the file system metadata.
https://github.com/Alluxio/alluxio/blob/aacf14507174029fac4a997b6037207fae92ea91/core/server/common/src/main/java/alluxio/master/journal/raft/RaftJournalSystem.java#L429
It'll be very helpful if the lifecycle state on the RaftServer is more up-to-date and more ideally, we can see what error caused RaftServer to fail. It is fair if you say we don't expose the exception outside RaftServer (because the external party normally can't do better recovery than the RaftServer is capable of), but it could be more extensible to future use cases if we do expose the exception out of RaftServer. WDYT?

szetszwo · 2022-09-05T12:32:29Z

@jiacheliu3 , What do you think about exposing the exception on the RaftServer?

It is a good idea. We can do it by passing an UncaughtExceptionHandler; see https://issues.apache.org/jira/secure/attachment/13048963/733_review.patch

jiacheliu3 · 2022-09-09T08:40:56Z

ratis-server-api/src/main/java/org/apache/ratis/server/RaftServer.java

    private static final Method NEW_RAFT_SERVER_METHOD = initNewRaftServerMethod();

    private static Method initNewRaftServerMethod() {
+      // TODO(jiacheng): backward compatibility?


Consider how to keep the most backward compatibility as possible

jiacheliu3 · 2022-09-15T04:33:34Z

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java

      return this;
    }

+    public Builder setUncaughtExceptionHandler(UncaughtExceptionHandler exceptionHandler) {


Not sure how much UT would be necessary. If necessary, I'll try writing something similar to RaftStateMachineExceptionTests using a MiniRaftCluster which creates a RaftServer with my user defined UncaughtExceptionHandler, and when I throw an exception internally, check if the handler is able to catch that.

szetszwo

@jiacheliu3 , thanks for the update! After checked the Java API in more details, it seems better to pass a ThreadGroup instead a UncaughtExceptionHandler (sorry that it was a bad idea); see https://issues.apache.org/jira/secure/attachment/13049347/733_review.patch

szetszwo · 2022-09-15T07:54:46Z

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java

+  static final Logger LOG = LoggerFactory.getLogger(Daemon.class);
+  public static final Thread.UncaughtExceptionHandler LOG_EXCEPTION =
+      (t, e) -> LOG.error(t.getName() + " threw an uncaught exception", e);


JVM already has a default UncaughtExceptionHandler (which prints out the exception to the System.err). Also, it has an API https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler- . We probably should not have a different default. If we do that, applications using Thread.setDefaultUncaughtExceptionHandler will not work.

jiacheliu3 · 2022-09-16T06:31:34Z

@jiacheliu3 , thanks for the update! After checked the Java API in more details, it seems better to pass a ThreadGroup instead a UncaughtExceptionHandler (sorry that it was a bad idea); see https://issues.apache.org/jira/secure/attachment/13049347/733_review.patch

@szetszwo Thanks for the suggestion that makes sense to me. One subtle implication I'm not sure about is, if the ThreadGroup is left null when creating a thread, that thread uses the current thread's ThreadGroup: code

I'm not 100% sure what that suggests. Specifically I'm not sure if threads from TimeoutScheduler.newExecutor() code will implicitly also inherit this ThreadGroup and uncaught exceptions there will propagate to the application in the same way. Is that true and is that desirable? In other words I imagine there are critical threads whose uncaught exceptions should crash the RaftServer, whereas there are unimportant threads whose crashes should be somehow tolerated and just generate a warning at most.

In contrast if we specify an UncaughtExceptionHandler in the old way, it is possible to distinguish the critical threads from the others. Not saying setUncaughtExceptionHandler() doesn't have downsides, just saying it's easier to manually configure.

codings-dan

@jiacheliu3 Thanks a lot for working on this , overall lgtm, left some comments for ref

codings-dan · 2022-09-16T13:11:33Z

ratis-server/src/main/java/org/apache/ratis/server/leader/LogAppenderDaemon.java

  private final LogAppender logAppender;

-  LogAppenderDaemon(LogAppender logAppender) {
+  LogAppenderDaemon(LogAppender logAppender, RaftServer.Division server) {


Is it possible to pass in a ThreadGroup here instead of passing in a RaftServer.Division

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

szetszwo

@jiacheliu3 , thanks for the update! Some comments inlined.

ratis-server-api/src/main/java/org/apache/ratis/server/RaftServer.java

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

szetszwo · 2022-09-19T09:11:38Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

  private final ExecutorService executor;

  private final JvmPauseMonitor pauseMonitor;
+  @Nullable


Let's create a default ThreadGroup and make it non-nullable.

Actually I figure a null here is fine. doc specifies that is the ThreadGroup arg is null, the current thread's group is inherited. That behavior can be better than we guess a default here?

Interestingly... OpenJDK does not really respect a null ThreadGroup here and throws NPE on me. I will change this to non-null.

szetszwo · 2022-09-19T09:13:02Z

ratis-server/src/main/java/org/apache/ratis/server/impl/ServerImplUtils.java

  public static RaftServerProxy newRaftServer(
      RaftPeerId id, RaftGroup group, RaftStorage.StartupOption option, StateMachine.Registry stateMachineRegistry,
-      RaftProperties properties, Parameters parameters) throws IOException {
+      RaftProperties properties, Parameters parameters, ThreadGroup threadGroup)


Please reorder the parameters:

ThreadGroup threadGroup, RaftProperties properties, Parameters parameters)

Rearranged together with all the places that have the same argument list

jiacheliu3 · 2022-09-19T15:15:02Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

    final TimeDuration leaderStepDownWaitTime = RaftServerConfigKeys.LeaderElection.leaderStepDownWaitTime(properties);
    this.pauseMonitor = new JvmPauseMonitor(id,
        extraSleep -> handleJvmPause(extraSleep, rpcSlownessTimeout, leaderStepDownWaitTime));
+    this.threadGroup = threadGroup == null ? new ThreadGroup("raft-server-proxy") : threadGroup;


i figure it's safer to do the null check here than in the Builder

Here I'm just applying a ThreadGroup that has no unhandledException(). In the future if it's proved to be needed I can submit another PR for a better default ThreadGroup.

No default uncaughtException(..) probably is okay since it will use the system default.

jiacheliu3 · 2022-09-21T01:20:17Z

@szetszwo PTAL if the changes look good to me. I suppose the comments are mostly resolved so it'll be a quick one :) Thanks!

szetszwo

@jiacheliu3 , thanks for the update! Just some minor comments inlined.

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

szetszwo · 2022-09-21T04:31:00Z

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerProxy.java

    final TimeDuration leaderStepDownWaitTime = RaftServerConfigKeys.LeaderElection.leaderStepDownWaitTime(properties);
    this.pauseMonitor = new JvmPauseMonitor(id,
        extraSleep -> handleJvmPause(extraSleep, rpcSlownessTimeout, leaderStepDownWaitTime));
+    this.threadGroup = threadGroup == null ? new ThreadGroup("raft-server-proxy") : threadGroup;


No default uncaughtException(..) probably is okay since it will use the system default.

ratis-server/src/test/java/org/apache/ratis/server/impl/MiniRaftCluster.java

jiacheliu3 · 2022-09-21T06:33:01Z

This test passes on my local PC, I believe this one is flaky.

Error:  Failures: 
Error:    TestLeaderElectionWithSimulatedRpc>LeaderElectionTests.testEnforceLeader:284->LeaderElectionTests.enforceLeader:298 expected:<s[1]> but was:<s[3]>

codings-dan · 2022-09-21T06:45:57Z

Let me re-run the failed-job.

szetszwo

+1 the change looks good.

(cherry picked from commit 31eff22)

jiacheliu3 added 2 commits September 3, 2022 16:01

init commit

84af089

improve API

11c5469

jiacheliu3 commented Sep 3, 2022

View reviewed changes

ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java Outdated Show resolved Hide resolved

jiacheliu3 commented Sep 3, 2022

View reviewed changes

jiacheliu3 added 2 commits September 3, 2022 19:15

improve the todos somehow

7a75248

consolidate Daemon constructors to use Builder pattern

17f7fc2

jiacheliu3 commented Sep 3, 2022

View reviewed changes

ratis-common/src/main/java/org/apache/ratis/util/Daemon.java Show resolved Hide resolved

minor improvements

68f6a76

jiacheliu3 added 7 commits September 5, 2022 10:47

add license

4ca2d87

fix some tests

17d2e9e

improve builder

f80a88b

fix TimeoutScheduler test

4777d5c

fix tests

705c4eb

remove extra prints

eb76c1a

checkstyle

66cac90

szetszwo requested changes Sep 5, 2022

View reviewed changes

resolve some comments

ec50556

codings-dan mentioned this pull request Sep 9, 2022

RATIS-1677. Do not auto format RaftStorage in RECOVER. #718

Merged

supply uncaughtExceptionHandler from application

c694ddf

jiacheliu3 commented Sep 9, 2022

View reviewed changes

jiacheliu3 commented Sep 15, 2022

View reviewed changes

szetszwo reviewed Sep 15, 2022

View reviewed changes

use ThreadGroup instead of UncaughtExceptionHandler

9ce1281

jiacheliu3 changed the title ~~RATIS-1709 Support passing UncaughtExceptionHandler from app to RaftServer~~ RATIS-1709 Support specify ThreadGroup for Ratis threads Sep 16, 2022

jiacheliu3 changed the title ~~RATIS-1709 Support specify ThreadGroup for Ratis threads~~ RATIS-1709 Support specify ThreadGroup for Daemon threads Sep 16, 2022

jiacheliu3 requested a review from szetszwo September 16, 2022 06:31

codings-dan reviewed Sep 16, 2022

View reviewed changes

resolve a minor comment

00681d9

jiacheliu3 requested review from codings-dan and szetszwo and removed request for codings-dan and szetszwo September 16, 2022 14:57

resolve comments

53ba4b9

szetszwo reviewed Sep 19, 2022

View reviewed changes

jiacheliu3 added 2 commits September 19, 2022 23:11

resolve comments

b824308

comment

05575a7

jiacheliu3 commented Sep 19, 2022

View reviewed changes

jiacheliu3 requested a review from szetszwo September 19, 2022 15:16

szetszwo reviewed Sep 21, 2022

View reviewed changes

resolve comments

2ddce34

jiacheliu3 requested a review from szetszwo September 21, 2022 06:33

szetszwo approved these changes Sep 21, 2022

View reviewed changes

szetszwo merged commit 31eff22 into apache:master Sep 21, 2022

codings-dan pushed a commit to codings-dan/incubator-ratis that referenced this pull request Sep 21, 2022

RATIS-1709 Support specify ThreadGroup for Daemon threads (apache#733)

48676aa

(cherry picked from commit 31eff22)

codings-dan pushed a commit that referenced this pull request Sep 30, 2022

RATIS-1709 Support specify ThreadGroup for Daemon threads (#733)

58389a6

(cherry picked from commit 31eff22)

symious pushed a commit to symious/ratis that referenced this pull request Mar 11, 2024

RATIS-1709 Support specify ThreadGroup for Daemon threads (apache#733)

a859362

Conversation

jiacheliu3 commented Sep 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes were proposed in this pull request?

What is the link to the Apache JIRA

How was this patch tested?

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jiacheliu3 commented Sep 3, 2022

Uh oh!

codings-dan commented Sep 4, 2022

Uh oh!

szetszwo commented Sep 5, 2022

Uh oh!

jiacheliu3 commented Sep 5, 2022

Uh oh!

codings-dan commented Sep 5, 2022

Uh oh!

szetszwo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jiacheliu3 commented Sep 5, 2022

Uh oh!

szetszwo commented Sep 5, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

szetszwo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jiacheliu3 commented Sep 16, 2022

Uh oh!

codings-dan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

szetszwo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jiacheliu3 commented Sep 3, 2022 •

edited

Loading