[
https://issues.apache.org/jira/browse/HBASE-22460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated HBASE-22460:
---------------------------------
Release Note:
Leaked store files can not be removed even after it is invalidated via
compaction. A reasonable mitigation for a reader reference leak would be a fast
reopen of the region on the same server.
Configs:
1. hbase.master.regions.recovery.check.interval :
Regions Recovery Chore interval in milliseconds. This chore keeps running at
this interval to find all regions with configurable max store file ref count
and reopens them.
2. hbase.regions.recovery.store.file.ref.count :
This config represents Store files Ref Count threshold value considered for
reopening regions. Any region with store files ref count > this value would be
eligible for reopening by master. Default value -1 indicates this feature is
turned off. Only positive integer value should be provided to enable this
feature.
> Reopen a region if store reader references may have leaked
> ----------------------------------------------------------
>
> Key: HBASE-22460
> URL: https://issues.apache.org/jira/browse/HBASE-22460
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 3.0.0, 1.5.0, 2.3.0
> Reporter: Andrew Kyle Purtell
> Assignee: Viraj Jasani
> Priority: Minor
> Fix For: 3.0.0, 2.3.0
>
>
> We can leak store reader references if a coprocessor or core function somehow
> opens a scanner, or wraps one, and then does not take care to call close on
> the scanner or the wrapped instance. A reasonable mitigation for a reader
> reference leak would be a fast reopen of the region on the same server
> (initiated by the RS) This will release all resources, like the refcount,
> leases, etc. The clients should gracefully ride over this like any other
> region transition. This reopen would be like what is done during schema
> change application and ideally would reuse the relevant code. If the refcount
> is over some ridiculous threshold this mitigation could be triggered along
> with a fat WARN in the logs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
