Vivek1106-04 commented on issue #12441: URL: https://github.com/apache/seatunnel/issues/12441#issuecomment-5806797054
@Rangsh thanks for taking this. The direction and @DanielLeens's four constraints look right to me. One requirement was settled on the STIP thread (#12339, [SEZ9](https://github.com/apache/seatunnel/issues/12339) and DanielLeens) after your plan was posted. It moves a regression test out of #12165 and into this issue, so I am recording it here as agreed. **The regression is required for this fix, and it must be written red first.** Your plan says full occupancy of the shared dispatch pool is not a merge gate. It does not have to be reproduced as an incident. But the regression below is how this issue closes, and it must fail against the current blocking lock acquisition before the fix makes it pass. What it has to show: 1. **Same coordinator (works on `dev` today).** Hold `pendingCounter > 0`, start `startSavepoint()`, then call `tryTriggerPendingCheckpoint` on the same coordinator. Before the fix it blocks for the full drain. That is the red run. After the fix it returns within a bound far below the drain time, creates no pending checkpoint, and re-arms. This is your test 1 plus the gate check from test 2. The only extra requirement is to run it against current `dev` first and show it fails. 2. **Cross-pipeline (needs the shared scheduler from #12165).** Fill dispatch capacity with coordinators that are in a savepoint drain. Assert that an unrelated pipeline still gets its periodic trigger and its timeout watchdog on time. Before the fix, the contended coordinators hold every dispatch thread, so the unrelated pipeline starves. That is the red run. After the fix it is served. Part 2 has an ordering dependency. The shared dispatch pool only exists with #12165, so part 2 can only go red on a base that contains it: - If #12165 merges first, both parts land in this PR. - If this fix is ready first, it can land with part 1. Part 2 is then added as soon as #12165 is in, and I will write it myself. Either way, this issue stays open until part 2 has been shown red then green. Please put the red run in the PR description for each part: which test, which base revision, and the failure you saw. Everything else in DanielLeens's constraints stands unchanged. That includes keeping #12442's trigger-failure policy out of this change. -- 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]
