MartijnVisser opened a new pull request, #29533:
URL: https://github.com/apache/flink/pull/29533
## What is the purpose of the change
Fixes the exit code 239 fork crash in `FineGrainedSlotManagerTest`
(FLINK-34427). `runTest` returned without waiting for `close()`, so `afterAll`
could shut the executor down under a running requirements check:
```
ERROR org.apache.flink.util.FatalExitExceptionHandler [] - FATAL: Thread
'pool-429-thread-1' produced an uncaught exception. Stopping the process...
java.util.concurrent.CompletionException:
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@44a6cb42[...]
at
org.apache.flink.runtime.resourcemanager.slotmanager.DefaultSlotStatusSyncer.allocateSlot(DefaultSlotStatusSyncer.java:148)
```
This replaces #29301 by @snuyanzin, whose cancels in `suspend()` and
`DefaultSlotStatusSyncer#close()` miss a check that is already running. The
slot manager's own scheduling after `suspend()`, which @zentol raised on the
ticket, is a separate change.
## Brief change log
- `runTest` waits for `close()`. A failing `close()` now fails the test
instead of ending the JVM through `FutureUtils#assertNoException`.
## Verifying this change
This change is already covered by existing tests, such as
`FineGrainedSlotManagerTest` and `AbstractFineGrainedSlotManagerITCase`.
Measured in a Linux container pinned to one CPU, with surefire's JVM arguments
and the CI log4j config:
- With a `requestSlot` that blocks until the executor is shut down (at
most 2 s), master (855597a5460) crashes with the CI stack trace in 10 of 10
JVMs and this change in 0 of 30 class runs. Same on release-2.3 and release-2.2
(JDK 17) and on release-1.20 (JDK 8).
- Without the blocking `requestSlot`, master on JDK 17 crashes in 4 of 306
class runs, and with this change 0 of 800. The same loop on the previous base
5af0f51cfe4 gave 12 of 498 and 0 of 800. release-1.20 on JDK 8 crashes in 8 of
329, and with this change 0 of 1500.
- The slot manager tests pass on all four branches.
A test that fails while a check is still running still skips `close()` and
can crash the fork the same way; I'll file a follow-up for that.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): no
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? no
- If yes, how is the feature documented? not applicable
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Claude Opus 5.5, Claude Fable 5.1)
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
