amaliujia commented on a change in pull request #188:
URL: https://github.com/apache/incubator-ratis/pull/188#discussion_r483156528
##########
File path:
ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java
##########
@@ -1171,6 +1177,26 @@ public InstallSnapshotReplyProto
installSnapshot(InstallSnapshotRequestProto req
return reply;
}
+ @Override
+ public PauseReplyProto pause(PauseRequestProto request) throws IOException {
+ assertLifeCycleState(LifeCycle.States.RUNNING);
+ // TODO: should pause() be limited on only working for a follower?
+ if (!lifeCycle.compareAndTransition(RUNNING, PAUSING)) {
+ return PauseReplyProto.newBuilder().setSuccess(false).build();
+ }
+
+ // Now the state of lifeCycle should be PAUSING, which will prevent future
other operations.
+ // Pause() should pause ongoing operations:
+ // a. call {@link StateMachine#pause()}.
+ synchronized (this) {
+ // TODO: any other operations that needs to be paused?
+ stateMachine.pause();
+ }
Review comment:
so
1. Change state to pausing will (or at least should) prevent, e.g. new
AppendEntries.
2. `synchronized (this)` will guarantee that for those operations which get
lock before this pause code block, they should be able to finish.
However my current thought is, there could be still be a race condition,
when pause and other operations are competing this lock, and then pause wins,
other operations will still be executed after pause, which is wrong.
So the resolution can be adding an extra LifeCycle check after, e.g.
AppendEntriess, entering `synchronized (this)`, to make sure no pause has
happened.
WDYT?
##########
File path:
ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java
##########
@@ -1171,6 +1177,26 @@ public InstallSnapshotReplyProto
installSnapshot(InstallSnapshotRequestProto req
return reply;
}
+ @Override
+ public PauseReplyProto pause(PauseRequestProto request) throws IOException {
+ assertLifeCycleState(LifeCycle.States.RUNNING);
+ // TODO: should pause() be limited on only working for a follower?
+ if (!lifeCycle.compareAndTransition(RUNNING, PAUSING)) {
+ return PauseReplyProto.newBuilder().setSuccess(false).build();
+ }
+
+ // Now the state of lifeCycle should be PAUSING, which will prevent future
other operations.
+ // Pause() should pause ongoing operations:
+ // a. call {@link StateMachine#pause()}.
+ synchronized (this) {
+ // TODO: any other operations that needs to be paused?
+ stateMachine.pause();
+ }
Review comment:
so
1. Change state to pausing will (or at least should) prevent, e.g. new
AppendEntries.
2. `synchronized (this)` will guarantee that for those operations which get
lock before this pause code block, they should be able to finish.
However my current thought is, there could be still be a race condition,
when pause and other operations are competing this lock, and then pause wins,
other operations will still be executed after pause, which is wrong.
So the resolution can be adding an extra LifeCycle check after, e.g.
AppendEntries, entering `synchronized (this)`, to make sure no pause has
happened.
WDYT?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
