You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Nick Dimiduk (Jira)" <ji...@apache.org> on 2020/03/26 16:53:00 UTC
[jira] [Resolved] (HBASE-23258) Reconsider the DBB memory leak in
the exceptional paths.
[ https://issues.apache.org/jira/browse/HBASE-23258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Dimiduk resolved HBASE-23258.
----------------------------------
Fix Version/s: (was: 2.3.0)
(was: 3.0.0)
Resolution: Not A Problem
Closing -- it is believed that this was addressed by HBASE-22480.
> Reconsider the DBB memory leak in the exceptional paths.
> --------------------------------------------------------
>
> Key: HBASE-23258
> URL: https://issues.apache.org/jira/browse/HBASE-23258
> Project: HBase
> Issue Type: Bug
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
>
> Have a discussion with [~anoop.hbase], we find still have some exceptional paths which we did not handle DBB#release correctly. More details are the following:
> {code}
> > HFileReaderImpl#validateBlockType - When throws Exception, the get block is gone. Want to return?
> Yeah, we've two cases to validateBlockType. one is reading from cache, another one is reading from hfile.
> we've abstracted the block for both cache types and hfiles ( ex release the block from heap will donothing), so
> here seems we should do release if throws IOException.
> > Only inside another condition we return and evict block
> readBlock - The got block is unused when we throw Exception on DBE type mismatch
> Em..we return null finally , seems the block also need to release the block.
> {code}
> Will take a look around all the exceptional paths and consider any other DBB leak issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)