[
https://issues.apache.org/jira/browse/HBASE-22460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863706#comment-16863706
]
Anoop Sam John commented on HBASE-22460:
----------------------------------------
It make sense IMO. We are solving all ref count based bugs in our code and
even CP apps like Phoenix going to take care abt the proper closure of
scanners. Still this is a last chance for saving ourselves. Make sense. Ya we
might have logic to do this restart of region. Only thing new needed is
tracking of the count and decision making for restart.
bq.If the refcount is over some ridiculous threshold this mitigation could be
triggered along with a fat WARN in the logs
May be we should do like the refCount is really up over a number and continue
there for some time (all configurable) and then decide for doing this
mitigation? Count alone would be enough if this number is really really large!
Just asking.
> 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
> Reporter: Andrew Purtell
> Priority: Minor
>
> 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
(v7.6.3#76005)
