[HIVE-23606] LLAP: Delay In DirectByteBuffer Clean Up For EncodedReaderImpl

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0
• Fix Version/s: 4.0.0-alpha-1
• Component/s: llap
• Labels: pull-request-available
• Assignee: Syed Shameerur Rahman
• Reporter: Syed Shameerur Rahman
• Created: 04/Jun/20 05:25
• Updated: 17/Nov/22 08:48
• Resolved: 04/Jun/20 07:16

Description

DirectByteBuffler are only cleaned up when there is Full GC or manually invoked cleaner method of DirectByteBuffer, Since full GC may take some time to kick in, In the meanwhile the native memory usage of LLAP daemon process might shoot up and this will force the YARN pmem monitor to kill the container running the daemon.

HIVE-16180 tried to solve this problem, but the code structure got messed up after HIVE-15665

The IdentityHashMap (toRelease) is initialized in https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/io/orc/encoded/EncodedReaderImpl.java#L409 , but it is getting re-initialized inside the method getDataFromCacheAndDisk() https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/io/orc/encoded/EncodedReaderImpl.java#L633 which makes it local to that method hence the original toRelease IdentityHashMap remains empty.

Issue Links

• links to: GitHub Pull Request #1057