[
https://issues.apache.org/jira/browse/HBASE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452718#comment-13452718
]
Gary Helmling commented on HBASE-5448:
--------------------------------------
{quote}
... should that be back to the client in the above or do you mean passing
exceptions from client to server?
{quote}
For the current implementation, I mean passing exceptions back up from
coprocessor endpoint Service implementations, back up to
HRegionServer.execService() where it can be re-thrown as a ServiceException
(and sent back to the client by the RPC server). See AccessController.grant()
for an example:
{code:java}
try {
grant(perm);
response = AccessControlProtos.GrantResponse.getDefaultInstance();
} catch (IOException ioe) {
// pass exception back up
ResponseConverter.setControllerException(controller, ioe);
}
{code}
The PB-generated Service sub-class only defines the async/callback based
methods which do not throw ServiceException, so ServerRpcController provides an
alternate (though maybe not so natural) channel for communicating the
exception. But if this is useful on the server-side maybe it would be useful
in client-side invocations as well?
{quote}
Same rpccontroller for dynamic cp endpoints or you mean in general (Sorry if
dumb question – I don't know what the rpccontroller thing is about.. need to go
read up).
{quote}
Same ServerRpcController for clients invoking dynamic CP endpoints (if that's
useful), and a bit of doc around that.
{quote}
The bit of code pasted looks reasonable (I was going to say 'natural' but
that'd be going too far... I think you know what I mean... when folks see a pb
service, they know they got some building to do....)
{quote}
Yes, agree it's not quite as transparent as the proxy-based approach for
CoprocessorProtocol, but I don't see any easy way other than exposing the PB
Messages and Service directly.
{quote}
On #1, above, that means we can't just drop Writable in the rpc for 0.96
because you are thinking of supporting old and new in 0.96? (... I should go
back to the dev list and make sure we are all good w/ this... but that is my
understanding).
{quote}
Yes, that's true. Deprecating would keep the current Exec/ExecResult and
required handling of Writable params in place for 0.96. Since the way we
expose CP endpoints is an aspect of client interface, that seemed like the
fairest approach. Though if we poll the dev-list and there are no major
objections, I could see making an exception to be able to phase out all
Writable usage. In the very short-term, keeping both paths in place will allow
switching over current CP endpoints piece-by-piece without breakage.
> Support for dynamic coprocessor endpoints with PB-based RPC
> -----------------------------------------------------------
>
> Key: HBASE-5448
> URL: https://issues.apache.org/jira/browse/HBASE-5448
> Project: HBase
> Issue Type: Sub-task
> Components: ipc, master, migration, regionserver
> Reporter: Todd Lipcon
> Assignee: Gary Helmling
> Attachments: HBASE-5448.patch
>
>
--
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
