SEZ9 commented on PR #11727:
URL: https://github.com/apache/seatunnel/pull/11727#issuecomment-5642957326

   Thanks for the update on `f1e02f942`. I haven't yet re-verified each of the 
earlier findings against this head, so rather than guess, could you note for 
each one whether it was addressed in `f1e02f942` or is intentionally deferred?
   
   - **F1 / F3** – whether the context and cancellation-future installation on 
the deploy side now happens under the same monitor that 
`finishOwnedResources()` uses (closing the redeploy-vs-taskDone race), or 
whether the Javadoc was adjusted to describe what is actually guaranteed.
   - **F2** – whether `BlockingWorker` now resolves its context from the 
tracker's `ownedContext` instead of the shared `executionContexts` map, so a 
reused `TaskGroupLocation` cannot hand it a newer generation's context/class 
loader.
   - **F4 / F5** – whether the stale-cleanup path now cancels the old 
generation's async functions and timer-flush tasks, and whether installing the 
new context still uses a plain `put` that could overwrite a still-live older 
entry. Handling both in one place (detect the live older generation, tear its 
resources down, then install) would resolve them together.
   - **F6** – if the teardown runs under the service-wide monitor, please 
consider moving the class-loader release and cancellation work outside the 
locked section and keeping only the map mutations under the lock.
   - **F8** – `remove(key, value)` alone is sufficient, so the preceding `get` 
can go. Please also say whether the stale path should move `ownedContext` into 
`finishedExecutionContexts`, or why it intentionally does not.
   
   **F7** – deferring the redeploy-vs-taskDone race test is fine with me as 
long as the PR description records that explicitly; the reflection-based access 
into `TaskExecutionService` internals is acceptable for now.
   
   Once I have that per-finding status, I'll do a final pass on the head.
   
   <!-- streview-comment:982 -->


-- 
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]

Reply via email to