[
https://issues.apache.org/jira/browse/HBASE-26812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509304#comment-17509304
]
Lars Hofhansl edited comment on HBASE-26812 at 3/19/22, 4:46 PM:
-----------------------------------------------------------------
[~comnetwork] It might be. In the slow case it finishes eventually, though.
In the profiler I see that much is spent in getting the quota and there in
getting the user and there in Java access controller (I think, can't easily
check right now).
When conditions are such that all data is read during openScanner the problem
does not occur, but when further calls to next to are needed, then it becomes
slow. Sorry for being so vague - little time for this right now.
See also PHOENIX-6671, which fixes the problem.
was (Author: lhofhansl):
[~comnetwork] It might be. In the slow case it finishes eventually, though.
In the profiler I see that much is spent in getting the quota and there in
getting the user and there in Java access controller (I think, can't easily
check right now).
When conditions are such that all data is read during openScanner the problem
does not occur, but when further calls to next to are needed, then it becomes
slow. Sorry for being so vague.
See also PHOENIX-6671, which fixes the problem.
> ShortCircuitingClusterConnection fails to close RegionScanners when making
> short-circuited calls
> ------------------------------------------------------------------------------------------------
>
> Key: HBASE-26812
> URL: https://issues.apache.org/jira/browse/HBASE-26812
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.4.9
> Reporter: Lars Hofhansl
> Priority: Critical
>
> Just ran into this on the Phoenix side.
> We retrieve a Connection via
> {{{}RegionCoprocessorEnvironment.createConnection... getTable(...){}}}. And
> then call get on that table. The Get's key happens to be local. Now each call
> to table.get() leaves an open StoreScanner around forever. (verified with a
> memory profiler).
> There references are held via
> RegionScannerImpl.storeHeap.scannersForDelayedClose. Eventially the
> RegionServer goes into a GC of death and can only ended with kill -9.
> The reason appears to be that in this case there is no currentCall context.
> Some time in 2.x the Rpc handler/call was made responsible for closing open
> region scanners, but we forgot to handle {{ShortCircuitingClusterConnection}}
> It's not immediately clear how to fix this. But it does make
> ShortCircuitingClusterConnection useless and dangerous. If you use it, you
> *will* create a giant memory leak.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
