tillrohrmann commented on a change in pull request #14963:
URL: https://github.com/apache/flink/pull/14963#discussion_r579105092
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/scheduler/declarative/DeclarativeScheduler.java
##########
@@ -907,20 +909,37 @@ public void runIfState(State expectedState, Runnable
action, Duration delay) {
// ----------------------------------------------------------------
+ /** Note: Do not call this method from a State constructor. */
@VisibleForTesting
- void transitionToState(State newState) {
- if (state != newState) {
- LOG.debug(
- "Transition from state {} to {}.",
- state.getClass().getSimpleName(),
- newState.getClass().getSimpleName());
-
- State oldState = state;
- oldState.onLeave(newState.getClass());
-
- state = newState;
- newState.onEnter();
- }
+ <S extends State> void transitionToState(StateFactory<S> targetState) {
+ Preconditions.checkState(
+ state != null, "State transitions are now allowed while
construcing a state.");
+ Preconditions.checkState(
+ state.getClass() != targetState.getStateClass(),
+ "Attempted to transition into the very state the scheduler is
already in.");
+
+ LOG.debug(
+ "Transition from state {} to {}.",
+ state.getClass().getSimpleName(),
+ targetState.getStateClass().getSimpleName());
+
+ State oldState = state;
+ oldState.onLeave(targetState.getStateClass());
+
+ // Guard against state transitions while constructing state objects.
+ //
+ // Consider the following scenario:
+ // Scheduler is in state Restarting, once the cancellation is
complete, we enter the
+ // transitionToState(WaitingForResources) method.
+ // In the constructor of WaitingForResources, we call
`notifyNewResourcesAvailable()`, which
+ // finds resources and enters transitionsToState(Executing). We are in
state Executing. Then
+ // we return from the methods and go back in our call stack to the
+ // transitionToState(WaitingForResources) call, where we overwrite
Executing with
+ // WaitingForResources. And there we have it, a deployed execution
graph, and a scheduler
+ // that is in WaitingForResources.
+ state = null;
Review comment:
Theoretically, we could remember in the `transitionToState` method
whether we are currently doing a state transition. If this is the case, then we
enqueue the `targetState` in some queue. If not, then we set the flag that we
are transitioning into a new state and do the state transition. Once we are
complete with a state transition we check the queue for enqueued state
transitions. Only if all state transitions are dequeued, we switch the flag
back to not doing a state transition.
----------------------------------------------------------------
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:
us...@infra.apache.org
