XComp commented on code in PR #23977:
URL: https://github.com/apache/flink/pull/23977#discussion_r1444473737
##########
flink-runtime/src/test/java/org/apache/flink/runtime/minicluster/MiniClusterITCase.java:
##########
@@ -127,6 +129,11 @@ private void runHandleJobsWhenNotEnoughSlots(final
JobGraph jobGraph) throws Exc
configuration.setLong(JobManagerOptions.SLOT_REQUEST_TIMEOUT, 100L);
// this triggers the failure for the adaptive scheduler
configuration.set(JobManagerOptions.RESOURCE_WAIT_TIMEOUT,
Duration.ofMillis(100));
+ // disable the resource requirements check from slot manager the make
sure the scheduler
+ // cannot acquire slots until timeout.
+ configuration.set(
Review Comment:
Thanks for the clarification. That sounds about right. I'm just wondering
whether we should then switch to testing the default behavior with the
fine-grained SlotManager triggering the `NoResourceAvailableException` rather
than relying on the timeout (which is some kind of fallback now). That would
only require updating the job configuration rather than changing the assert.
WDYT?
```java
// the fine-grained SlotManager should inform the JobMaster about missing
resourcesconfiguration.set(ResourceManagerOptions.REQUIREMENTS_CHECK_DELAY,
Duration.ofMillis(50L));
// the slot timeout needs to be high enough for the timeout to not cause the
// NoResourceAvailableException, instead
long slotRequestTimeoutInMillis = 10_000L;
// this triggers the failure for the default scheduler
configuration.setLong(JobManagerOptions.SLOT_REQUEST_TIMEOUT,
slotRequestTimeoutInMillis);
// this triggers the failure for the adaptive scheduler
configuration.set(
JobManagerOptions.RESOURCE_WAIT_TIMEOUT,
Duration.ofMillis(slotRequestTimeoutInMillis));
// cluster startup relies on SLOT_REQUEST_TIMEOUT as a fallback if the
following parameter
// is not set which causes the test to take longer
configuration.set(ResourceManagerOptions.STANDALONE_CLUSTER_STARTUP_PERIOD_TIME,
1L);
```
--
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]
