DanielLeens opened a new issue, #12147: URL: https://github.com/apache/seatunnel/issues/12147
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue) and found no similar issues. ### What happened After a streaming job is cancelled and reaches `CANCELED`, the Zeta node still has the job's checkpoint coordinator thread alive. The e2e framework's post-job thread check (`SeaTunnelContainer` "There are still threads running in the container") catches it, and the two file-source continuous-discovery tests that cancel their job at the end fail with `Wait continuous job exit failed`: - PR #11757, fork run `waterWang/seatunnel` 33998012457, job `connector-file-sftp-it (11)` (job 101392143762): `SftpFileIT#testSftpBinaryUpdateModeContinuousDiscoveryPostSyncBackup`, Zeta leg. - PR #11727, fork run `abdessalems/seatunnel` 34022796412, job `all-connectors-it-5 (11)` (job 101458676526): `FtpFileIT#testFtpBinaryUpdateModeContinuousDiscoveryWithNonRecursiveScan`, Zeta leg. Both PRs touch neither the file connectors nor the checkpoint coordinator. ### Evidence Sequence in both runs: `container.cancelJob(jobId)` returns 0, `getJobStatus(jobId)` becomes `CANCELED` within the 30 s wait, the engine logs `Job <conf> turned from state CANCELING to CANCELED` and `Job (<id>) end with state CANCELED`, and then the thread check that `executeJob` runs after the job keeps reporting for 2 minutes: ``` There are still threads running in the container: "checkpoint-coordinator-1/5309008626678301139" #317 prio=5 os_prio=0 tid=... waiting on condition java.lang.Thread.State: WAITING (parking) - parking to wait for <0x00000000f58ff6d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ``` (the FTP run; the SFTP run shows the same single `checkpoint-coordinator-1/<jobId>` thread). The thread name is the per-job checkpoint coordinator executor of the JobMaster; it is parked on its queue, i.e. the executor was never shut down when the pipeline ended in `CANCELED`. ### What you expected to happen Cancelling a job must release the job's checkpoint coordinator executor together with the rest of the JobMaster resources, so no `checkpoint-coordinator-*` thread outlives a job that has reached a terminal state. The e2e thread-leak check exists precisely to catch this class of leak on the Zeta node. ### SeaTunnel Version dev (`96836fc6`), Zeta. ### Engine Zeta ### Additional context Only seen on the two continuous-discovery tests so far because they are among the few e2e cases that cancel a streaming job and then run the thread check; batch jobs end via `FINISHED` and do not show it. Filed while triaging CI for #11757 and #11727. -- 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]
