nielifeng commented on issue #11437: URL: https://github.com/apache/seatunnel/issues/11437#issuecomment-5041974843
I reproduced the same fixed-slot restore and cleanup failure again on current upstream `dev`, using a concurrent workload that occupies 15 of 16 fixed slots. Tested conditions: - `3.0.0-SNAPSHOT`, `dev` commit `dbead9b01fc42ddc5a7f8699311ebf52dbb5d937` - three Masters and two Workers, eight fixed slots per Worker - `job-schedule-strategy: WAIT`, `dynamic-slot: false`, checkpoint storage enabled - three streaming FakeSource -> Console jobs, parallelism 4 each - total allocation: 15 task groups/slots, one free slot All three jobs were `RUNNING`, had successful checkpoints with zero failures, and sustained normal throughput before terminating only the Active Master process. After the Master transition, all three jobs entered `PENDING/RESTORE`, QPS became zero, and no further checkpoint completed during a five-minute recovery window. The pending diagnostics for each job were: ```text totalTaskGroups=5, allocatedTaskGroups=0, lackingTaskGroups=5 failureReason=RESOURCE_NOT_ENOUGH failureMessage=Slot request future not created ``` The cluster still reported 15 assigned fixed slots while the restored jobs tried to allocate a new set of task groups. Cancelling all jobs cleared the running and pending job counts, but left only 1 of 16 slots free for more than two minutes. Restarting the two Worker services was required to restore all 16 slots. This confirms that #11437 remains reproducible on latest `dev` and extends the previous single-job evidence to concurrent fixed-slot workloads. The tested `dev` build does not include PR #11458, which remains open. -- 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]
