[
https://issues.apache.org/jira/browse/HBASE-11766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111875#comment-14111875
]
James Taylor commented on HBASE-11766:
--------------------------------------
Are there unit tests around running a scan from a coprocessor through the
env.getTable(TableName) API? We're seeing a case now where if we use
RegionCoprocessorEnvironment.getTable(TableName) to get the HTableInterface we
get no rows back from our ResultScanner. If we go through HTablePool, we get
rows back. This is from a coprocessor end point call and all the data is local
to the region.
Would this fix have fixed that as well?
> Backdoor CoprocessorHConnection is no longer being used for local writes
> ------------------------------------------------------------------------
>
> Key: HBASE-11766
> URL: https://issues.apache.org/jira/browse/HBASE-11766
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.4
> Reporter: James Taylor
> Assignee: Andrew Purtell
> Labels: Phoenix
> Fix For: 0.99.0, 2.0.0, 0.98.6
>
> Attachments: HBASE-11766-0.98.patch, HBASE-11766.patch,
> HBASE-11766.patch
>
>
> There's a backdoor CoprocessorHConnection used to ensure that a batched
> mutation does not go over the wire and back, but executes immediately
> locally. This is leveraged by Phoenix during secondary index maintenance (for
> an ~20% perf improvement). It looks to me like it's no longer used, as the
> following function is never invoked:
> public
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos.ClientService.BlockingInterface
> getClient(ServerName serverName) throws IOException {
> It'd be good if feasible to add an HBase unit test to prevent further
> regressions. For more info, see PHOENIX-1166.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
