JackieTien97 opened a new pull request, #17204: URL: https://github.com/apache/iotdb/pull/17204
When SharedTsBlockQueue.add() encounters memory pressure, it registers an async listener on a MemoryReservationFuture to add the TsBlock later. If the upstream FragmentInstance finishes and calls abort()/close() before the listener executes, the following race occurs: 1. abort() sets closed=true, clears the queue, frees bufferRetainedSizeInBytes 2. deRegisterFragmentInstanceFromMemoryPool removes the upstream FI's memory mapping 3. The async listener fires and adds the TsBlock to the closed queue 4. The downstream consumer calls remove() -> MemoryPool.free() with the upstream FI's IDs, but the mapping no longer exists -> NPE Fix: Check the `closed` flag inside the async listener before adding the TsBlock. When closed, skip the add (memory was already freed by abort/close) and complete channelBlocked to prevent hangs. Also add a unit test that reproduces this race condition by using a manually-controlled SettableFuture to simulate the blocked-on-memory path. (cherry picked from commit 7ee7a83b86fc4d266c9c7aa45cccb0044b56daa6) -- 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]
