DanielLeens commented on issue #10993: URL: https://github.com/apache/seatunnel/issues/10993#issuecomment-4608235621
After checking the configuration and the failure log you posted, this looks closer to a resource-scheduling / cluster-sizing issue than to a new engine bug. The key point is that your cluster is configured with fixed slots: - `dynamic-slot: false` - worker `slot-num: 20` - `job-schedule-strategy: WAIT` With that setup, newly submitted jobs are expected to stay in `PENDING` once the available slots are exhausted, because `WAIT` means the scheduler will queue instead of reject. The stack trace you included is also a specific job failure path (`Timeout expired after 60000ms while awaiting InitProducerId`), not direct evidence that the scheduler itself is stuck. To narrow down whether there is still a real scheduling defect, please check these points: 1. the cluster slot status (`totalSlot` / `unassignedSlot`) at the time jobs remain pending 2. whether the reported `160 tasks` is a platform-side count rather than actual SeaTunnel running task groups 3. whether some earlier failed jobs were still holding slots after the OOM / restart window If your expectation is that all of these jobs should run concurrently, the current fixed-slot capacity is very small for that workload. Please first try validating the slot usage and scheduling pressure on the cluster side. If jobs still remain pending while `unassignedSlot > 0`, please update the thread with the master scheduling log and one stuck job's REST job info, and we can continue checking for a real scheduler bug. -- 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]
