You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Nick Dimiduk (Jira)" <ji...@apache.org> on 2020/03/23 23:46:00 UTC

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17065188#comment-17065188 ] 

Nick Dimiduk commented on HBASE-23258:
--------------------------------------

Bump [~openinx], [~binlijin] – status update?

> 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
>             Fix For: 3.0.0, 2.3.0
>
>
> 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)