[
https://issues.apache.org/jira/browse/HBASE-23349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013255#comment-17013255
]
Andrew Kyle Purtell commented on HBASE-23349:
---------------------------------------------
{quote}
I think we should step back and remember why we have the ref counting in the
first place. This came from a discussion started in HBASE-13082 and
HBASE-10060, namely too much synchronization.
If any changes we make now needs new synchronization in the scanner.next(...)
path we're back to where we started and in that case we should remove the ref
counting and bring back the old notification and scanner switching we had
before.
{quote}
I made a similar comment on an internal discussion yesterday. If we have to
walk back the StoreScanner "lock coarsening" work, then let's not be afraid to
do it. There is a nuanced decision we would have to make, but let's not be
concerned about sunk costs.
> 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)
