[
https://issues.apache.org/jira/browse/HBASE-23349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024085#comment-17024085
]
ramkrishna.s.vasudevan commented on HBASE-23349:
------------------------------------------------
[~stack], [~larsh], [~vjasani]
Just my thoughts here. Seems currently this ref counting issue happens due to
Phoenix not able to close the scanners properly in some cases. It is not coming
out of hbase. Correct me if am wrong here [~vjasani].
Next thing is that even recently a 1.3.0 user had faced issue with sync blocks
exactly the issue HBASE-13082 was trying to solve because the user had rows to
read with lots of deletes and frequent flushes/compactions were going on. For
all such cases this non sync way will help them.
Also I believe some of the features like external compaction may depend or make
use of this async way of removing the compacted files rather than as part of
the scan flow.
The code fix may become more uglier if we keep adding another boolean and have
two code paths either to do scanner reset as part of scans or just allow the
scanner to continue as is and do the async way of removals.
> Low refCount preventing archival of compacted away files
> --------------------------------------------------------
>
> Key: HBASE-23349
> URL: https://issues.apache.org/jira/browse/HBASE-23349
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 3.0.0, 2.3.0, 1.6.0
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
> Fix For: 3.0.0, 2.3.0, 1.6.0
>
>
> We have observed that refCount on compacted away store files as low as 1 is
> prevent archival.
> {code:java}
> regionserver.HStore - Can't archive compacted file
> hdfs://{{root-dir}}/hbase/data/default/t1/12a9e1112e0371955b3db8d3ebb2d298/cf1/73b72f5ddfce4a34a9e01afe7b83c1f9
> because of either isCompactedAway=true or file has reference,
> isReferencedInReads=true, refCount=1, skipping for now.
> {code}
> We should come up with core code (run as part of discharger thread)
> gracefully resolve reader lock issue by resetting ongoing scanners to start
> pointing to new store files instead of compacted away store files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
