[
https://issues.apache.org/jira/browse/HBASE-23349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989474#comment-16989474
]
Viraj Jasani commented on HBASE-23349:
--------------------------------------
It seems at least max refCount based metric is not going to help here. Let me
repurpose this Jira and the patch attached so far upto 002 can be ignored.
The major issue is client holding read lock on compacted files for longer time
and if we really want to tackle this gracefully, we might have to remove file
reader from open scanners and let open scanners use new store files - seems
tricky though.
Also, on the other hand, once reader lock is released, we can check if archival
of compacted files was blocked on this and if so, let the discharger thread run
forcefully then and there before someone else takes read lock - this might also
be tricky and not sure if it would be performant.
[~apurtell] [~anoop.hbase]
> Expose max refCount among all compacted store files of a region
> ---------------------------------------------------------------
>
> 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
>
>
> We should expose a region level metric that represents max refCount among
> refCounts of all compacted store files under the region. For successful
> archival of compacted store files, it is important for this metric count to
> be 0 eventually if not immediately. If it is >0 for a considerably high
> amount of time, it indicates some issue i.e. reader refCount leak on some
> compacted store files and in such case, archival would not be successful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
