[
https://issues.apache.org/jira/browse/HBASE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14335701#comment-14335701
]
Jonathan Lawlor commented on HBASE-13082:
-----------------------------------------
As it stands, whenever a client scanner receives results back from an RPC it
will check its size and caching limits. If neither of those limits have been
reached, the scanner assumes that the current region has been exhausted and it
will try to change regions. Thus, if we return an empty Result (i.e. a Result
with no cells in it) back to the scanner, it will see that neither limit has
been reached and will try to change the region. Also, the client side Scanner
will blindly add that result to the client side cache. The problem there is
that at some point, the user would call ClientScanner#next() and receive a
blank Result.
In the case of HBASE-11544 (rpc chunking), I prevent the region change in the
event that partial results are returned because it means that there are still
Results left in the region. As [~apurtell] has pointed out in HBASE-13090, a
similar concept could be borrowed here -- if the Result that is returned is
flagged as a timer_heartbeat Result (or something along those lines), skip the
region change and continue to make RPC's until we have exhausted the region
(when regions are completely exhausted, the RPC will return 0 Results to the
client). This would likely require some sort of flag in the Result data
structure so that the ClientScanner understands that it should continue to scan
against the current region.
> Coarsen StoreScanner locks to RegionScanner
> -------------------------------------------
>
> Key: HBASE-13082
> URL: https://issues.apache.org/jira/browse/HBASE-13082
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Attachments: 13082-test.txt, 13082.txt
>
>
> Continuing where HBASE-10015 left of.
> We can avoid locking (and memory fencing) inside StoreScanner by deferring to
> the lock already held by the RegionScanner.
> In tests this shows quite a scan improvement and reduced CPU (the fences make
> the cores wait for memory fetches).
> There are some drawbacks too:
> * All calls to RegionScanner need to be remain synchronized
> * Implementors of coprocessors need to be diligent in following the locking
> contract. For example Phoenix does not lock RegionScanner.nextRaw() and
> required in the documentation (not picking on Phoenix, this one is my fault
> as I told them it's OK)
> * possible starving of flushes and compaction with heavy read load.
> RegionScanner operations would keep getting the locks and the
> flushes/compactions would not be able finalize the set of files.
> I'll have a patch soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
