shuwenwei commented on PR #18272: URL: https://github.com/apache/iotdb/pull/18272#issuecomment-5043783788
Could you clarify which production interleaving this test is intended to reproduce? The failure log only proves that `SharedTsBlockQueue.remove()` called `MemoryPool.free()` after the FI/query reservation map had already been removed; it does not show that reservation was concurrent with deregistration. In the normal FI terminal path, `clearShuffleSinkHandle()`, `driver.close()`, and `releaseResourceWhenAllDriversAreClosed()` all happen before deregistration, while handle cleanup also cancels pending reservation futures using the same future lock used by `MemoryPool.free()`. The new test directly races `tryReserveForTest()` with deregistration and therefore bypasses these lifecycle guarantees. There is also an uncovered reverse interleaving in the proposed fix: if deregistration acquires the fragment lock first and removes the map, the waiting operation fails identity validation and `continue`s, but the next iteration dereferences a null `queryRelatedMemory`, resulting in another NPE. Could we add a deterministic test where deregistration wins first, and either document a concrete production caller that can still reserve after FI cleanup or handle the missing mapping explicitly? -- 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]
