[
https://issues.apache.org/jira/browse/HBASE-22460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wenhao updated HBASE-22460:
---------------------------
Description: * 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. (was: 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. )
> 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-alpha-1, 1.5.0, 2.3.0
> Reporter: Andrew Kyle Purtell
> Assignee: Viraj Jasani
> Priority: Minor
> Fix For: 3.0.0-alpha-1, 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.20.10#820010)
