Caideyipi commented on PR #18272:
URL: https://github.com/apache/iotdb/pull/18272#issuecomment-5044893608

   Good catch. I audited the production lifecycle and agree that the original 
description overstated what the failure log proves. In the normal FI terminal 
path, sink/driver/source cleanup happens before deregistration, and pending 
reservations are cancelled or completed under the future lock. I did not find a 
concrete normal-path caller that starts a new reservation after FI cleanup.
   
   I addressed the actionable reverse ordering in 7af40afe6a1:
   
   - added explicit missing query/fragment-map handling in `free`, 
`tryReserve`, and rollback, so a deregistration-first interleaving fails with a 
descriptive `IllegalArgumentException` instead of retrying into an NPE;
   - added a deterministic test that lets the reservation read the old fragment 
map, lets deregistration remove it first, and then resumes the reservation; it 
verifies that the operation fails explicitly and global reserved bytes remain 
zero;
   - kept the existing deterministic reservation-first test as defensive 
coverage of the `MemoryPool` API invariant.
   
   I also revised the PR title/description to distinguish this defensive 
hardening from the still-unproven production interleaving.
   
   Verification passed: `MemoryPoolTest` 24/24, Checkstyle, Spotless, and 
DataNode `test-compile` with the zh locale.
   


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