[
https://issues.apache.org/jira/browse/HBASE-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768958#comment-13768958
]
Jesse Yates commented on HBASE-9534:
------------------------------------
[[email protected]] yeah, I wasn't a big fan of making those interfaces
public. Alternative was throw an UnspportedOperationException if you try to hit
the master with that connection. Keeps the interfaces how they are, but given
that we will have this connection, we could just as easily use it to talk
locally to the master (though, as I mention in the description, its not really
worth it).
I'm ok rolling those back and going with the exception or marking them
InterfaceAudience.Private - former seems cleaner for the moment.
> Short-Circuit Coprocessor HTable access when on the same server
> ---------------------------------------------------------------
>
> Key: HBASE-9534
> URL: https://issues.apache.org/jira/browse/HBASE-9534
> Project: HBase
> Issue Type: Bug
> Reporter: Jesse Yates
> Assignee: Jesse Yates
> Labels: coprocessors, performance, regionserver
> Fix For: 0.98.0
>
> Attachments: hbase-9534-trunk-v0.patch
>
>
> Coprocessors currently create a full HTable when they want to write. However,
> we know that coprocessors must run from within an HBase server (either master
> or RS). For the master, its rare that we are going to be doing performance
> sensitive operations, but RS calls could be very time-intensive.
> Therefore, we should be able to tell when a call from a CP attempts to talk
> to the RS on which it lives and just short-circuit to calling that RS, rather
> than going the long way around (which does the full marshalling/unmarshalling
> of data, as well as going over the loopback interface).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
