DanielLeens opened a new issue, #12121: URL: https://github.com/apache/seatunnel/issues/12121
## Description This is a focused task for worker-side thread budgeting in `TaskExecutionService`. It is not a regression report. Verified at `dev` commit `97d461bc0773399d632fd078735736ecd44f5f0b`: - `TaskExecutionService.java:169-170` unbounded `LinkedBlockingDeque<TaskTracker> threadShareTaskQueue`; `:173-174` `executorService = newCachedThreadPool(new BlockingTaskThreadFactory())`; `:177-178` `RunBusWorkSupplier(executorService, threadShareTaskQueue)`. - The cooperative worker requeues unfinished tasks at the queue tail. `TaskCallTimer.timeoutAct` (`TaskCallTimer.java:130-143`) marks the current bus-work exclusive to a slow task and submits a new bus-work via `runBusWorkSupplier.runNewBusWork(false)`, so each slow cooperative call adds one more thread. Slot count bounds the number of task groups, not the number of threads or queue entries. No claim is made here about one thread per source split; the growth path is admitted engine tasks, callbacks, and promoted cooperative workers. ## Expected outcome - A per-slot and per-job budget for promoted cooperative workers, with metrics for active threads, queue depth, and promotions. - Any hard cap must still let source, coordinator, and sink tasks start and reach readiness; blocking the queue arbitrarily is not safe backpressure. - Test: deploy many slow cooperative tasks and assert a bounded thread ceiling with no readiness deadlock. -- 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]
