bbeaudreault commented on PR #4592: URL: https://github.com/apache/hbase/pull/4592#issuecomment-1173060059
@Apache9 here is the relevant passage for root cause: The issue occurs when reading a compressed block which is smaller but close to the size of ByteBuffAllocator's minSizeForReservoirUse.: - We will pass intoHeap = false to fsBlockReader.readBlockData, because the block is DATA or ENCODED_DATA. As such we will use ByteBuffAllocator. However, the block size is less than minSizeForReservoirUse, so ByteBuffAllocator will allocate an on-heap buffer (hasArray() == true) - The hasArray() value will determine whether to return an ExclusiveMemHFileBlock or SharedMemHFileBlock, in this case ExclusiveMemHFileBlock. - In HFileBlock.unpack, we will shallowClone the block, which will result in a new ExclusiveMemHFileBlock and pass along the same ByteBuffAllocator used before. - Next we call allocateBuffer, which will use the uncompressed size of the block. This new block size will be larger than minSizeForReservoirUse, so will be allocated off-heap - We'll call release() on the original block, which is a no-op because it was an ExclusiveMemHFileBlock - We'll return the unpacked block all the way up to our HFileReaderImpl/StoreFileScanner/etc - All of those upper level classes seem to properly close resources, either when the scanner is closed or when shipped() is called. - **Unfortunately since it's an ExclusiveMemHFileBlock (which overloads release() to be a no-op), but backed by a DirectByteBuffer, that buffer will never properly be released back to the pool. Instead it will be GC'd, resulting in the leak.** -- 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]
