[
https://issues.apache.org/jira/browse/HBASE-23349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989545#comment-16989545
]
ramkrishna.s.vasudevan commented on HBASE-23349:
------------------------------------------------
Sorry for being late here. Good comments and discussion over here.
If the refCount is making an issue - then I think previously the scanners were
notified that the new compacted files are created and on receiving the
notificaiton it just resets the heap.
I think to make things simple based on the timeout config (as discussed here)
that thread can notify the scanner to reset itself and ensuring that the
refCount is decremented and inturn the discharger thread in the next cycle can
archive the compacted files. Does that make sense here?
> Reader lock on compacted store files preventing archival of compacted 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
>
> Attachments: HBASE-23349.master.000.patch,
> HBASE-23349.master.001.patch, HBASE-23349.master.002.patch
>
>
> refCounts on compacted away store files as low as 1 can also 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 blocking reader lock if client or
> coprocessor has held the lock for significantly high amount of
> time(configurable - mostly same as discharger thread interval) or gracefully
> resolve reader lock issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
