[
https://issues.apache.org/jira/browse/HBASE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355381#comment-14355381
]
Andrew Purtell commented on HBASE-13082:
----------------------------------------
bq. To fix TestFromClientSideWithCoprocessor I need to change the coprocessor
API for preStoreScannerOpen in order to pass the correct lock object in.
That's unfortunate.
We could introduce a new API and use the compatibility trick [~busbey] did in
RegionCoprocessorHost for dispatching to old APIs if the CP has methods with
the old signature. Can we have the RegionCoprocessorHost set the lock member on
the returned StoreScanner if the old API was used? Should be safe, the consumer
of the new API shouldn't be *changing* the lock object, just using it.
Coprocessors using the old API might not lock where they should, but this may
or may not be a problem depending on what they want to do, and we could print a
big fat warning if we need to dispatch to the old API. Coprocessors updated to
use the new API will be fine.
> 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
> Assignee: Lars Hofhansl
> Attachments: 13082-test.txt, 13082-v2.txt, 13082-v3.txt,
> 13082-v4.txt, 13082.txt, 13082.txt, gc.png, gc.png, gc.png, hits.png,
> next.png, next.png
>
>
> 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)
