zentol commented on a change in pull request #14963:
URL: https://github.com/apache/flink/pull/14963#discussion_r578652262
##########
File path:
flink-runtime/src/test/java/org/apache/flink/runtime/scheduler/declarative/WaitingForResourcesTest.java
##########
@@ -57,10 +57,15 @@ public void testTransitionToExecuting() throws Exception {
try (MockContext ctx = new MockContext()) {
ctx.setHasEnoughResources(() -> true);
- WaitingForResources wfr =
- new WaitingForResources(ctx, log, RESOURCE_COUNTER,
Duration.ZERO);
ctx.setExpectExecuting(assertNonNull());
- wfr.onEnter();
+
+ new WaitingForResources(ctx, log, RESOURCE_COUNTER, Duration.ZERO);
+ // run delayed actions
+ for (ScheduledRunnable scheduledRunnable :
ctx.getScheduledRunnables()) {
+ if (!ctx.hasStateTransition()) {
Review comment:
so basically you want to run actions until you hit a state transition?
I think you could make this more obvious by checking for hasStateTransition
after running the action and existing the loop
##########
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.");
Review comment:
```suggestion
state != null, "State transitions are not allowed while
constructing a state.");
```
##########
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:
hmm well this is annoying; these kind of loops are driving me crazy in
the slot procotol...
what if all goToX methods would schedule the state transition instead, or if
transitionToState just schedules it? well that would be annoying during tests
wouldn't it...
##########
File path:
flink-runtime/src/test/java/org/apache/flink/runtime/scheduler/declarative/DeclarativeSchedulerTest.java
##########
@@ -389,49 +388,24 @@ public void
testGoToFinishedShutsDownCheckpointingComponents() throws Exception
}
@Test
- public void testTransitionToStateCallsOnEnter() throws Exception {
+ public void testTransitionToStateCallsOnLeave() throws Exception {
final DeclarativeScheduler scheduler =
new DeclarativeSchedulerBuilder(createJobGraph(),
mainThreadExecutor).build();
- final LifecycleMethodCapturingState firstState = new
LifecycleMethodCapturingState();
+ final LifecycleMethodCapturingState.Factory firstStateFactory =
+ new LifecycleMethodCapturingState.Factory();
+ final DummyState.Factory secondStateFactory = new DummyState.Factory();
- scheduler.transitionToState(firstState);
- assertThat(firstState.onEnterCalled, is(true));
- assertThat(firstState.onLeaveCalled, is(false));
- firstState.reset();
- }
-
- @Test
- public void testTransitionToStateCallsOnLeave() throws Exception {
- final DeclarativeScheduler scheduler =
- new DeclarativeSchedulerBuilder(createJobGraph(),
mainThreadExecutor).build();
+ scheduler.transitionToState(firstStateFactory);
- final LifecycleMethodCapturingState firstState = new
LifecycleMethodCapturingState();
- final DummyState secondState = new DummyState();
+ final LifecycleMethodCapturingState firstState =
+ (LifecycleMethodCapturingState) scheduler.getState();
Review comment:
you could simplify this bit by having a test factory that accepts an
constructed state. That's usually a nicer way to deal with factories.
##########
File path:
flink-runtime/src/test/java/org/apache/flink/runtime/scheduler/declarative/DeclarativeSchedulerTest.java
##########
@@ -479,6 +453,24 @@ public void testHowToHandleFailureUnrecoverableFailure()
throws Exception {
is(false));
}
+ @Test(expected = IllegalStateException.class)
+ public void testRepeatedTransitionIntoCurrentStateFails() throws Exception
{
+ final DeclarativeScheduler scheduler =
+ new DeclarativeSchedulerBuilder(createJobGraph(),
mainThreadExecutor).build();
+
+ final State state = scheduler.getState();
+
+ // safeguard for this test
+ assertThat(state, instanceOf(Created.class));
+
+ transitionToState(scheduler, new Created.Factory(scheduler, log));
+ }
+
+ private static <S extends State> void transitionToState(
Review comment:
do we really need this method?
----------------------------------------------------------------
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
