[
https://issues.apache.org/jira/browse/HBASE-22491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870938#comment-16870938
]
Hudson commented on HBASE-22491:
--------------------------------
Results for branch master
[build #1168 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/1168/]: (x)
*{color:red}-1 overall{color}*
----
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1168//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1168//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1168//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Separate the heap HFileBlock and offheap HFileBlock because the heap block
> won't need refCnt and save into prevBlocks list before shipping
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-22491
> URL: https://issues.apache.org/jira/browse/HBASE-22491
> Project: HBase
> Issue Type: Sub-task
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
> Attachments: HBASE-22491.HBASE-21879.v01.patch,
> HBASE-22491.HBASE-21879.v02.patch
>
>
> In here [1], [~anoop.hbase] has a comment:
> bq. There is a concern here. Even if the block is on an exclusive heap memory
> area, we will keep ref to that in this list. In a Phoenix Aggregation kind of
> use case where many blocks might get fetched and not immediately shipped, we
> are keeping the ref unwantedly here for longer time. This makes the GC not
> able to reclaim the heap memory area for the blocks. This might be a hidden
> bomb IMO. Its not good to remove the MemType. Lets create the block with
> memory type as EXCLUSIVE when the block data is on heap. The block might be
> coming from LRU cache or by fetching the block data from HDFS into heap
> memory area. When the block comes from off heap BC or if it is backed by a BB
> from the pool (While reading from HDFS, read into pooled BB) lets create the
> block with mem type as SHARED. Every block can have the retain and release
> method but let the EXCLUSIVE types do a noop here.
> We've a discussion about this, say need to address two thing in this jira:
> 1. separate the HFileBlock into shared or non-shared;
> 2. Make the retain/release of non-shared block as a noop, say don't do
> reference count change for heap block.
> 1. https://github.com/apache/hbase/pull/257/files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
