[ 
https://issues.apache.org/jira/browse/HBASE-23349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023559#comment-17023559
 ] 

Anoop Sam John commented on HBASE-23349:
----------------------------------------

The ref counting way of lazy deletion of compacted files was done primarily to 
avoid the syncronized blocks in the read path.  On that jira, the perf test 
results were with removal of all such i believe.  Later we had to fix one issue 
wrt memstore flush during the read and as part of that a volatile bool lookup 
came in the read path (during seek, next etc).  Am not sure whether some perf 
reports been taken after that. and now we were trying to add another volatile 
boolean.
Now it might be good to do a perf test comparing
current way (no sync blocks but with a volatile bool read)  VS change to old 
way with sync blocks - ref counting.
Not sure how easy/difficult it will be.
[~vjasani] You have some bandwidth for this?  Lets have an offline detailed 
discussion if so.  Can explain the old way before the ref counting came in (If 
u wish to do so)

> 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)

Reply via email to