[
https://issues.apache.org/jira/browse/HBASE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537300#comment-13537300
]
Gary Helmling commented on HBASE-5448:
--------------------------------------
[[email protected]] Comments below:
bq. A thought. I think this pb-based way of doing dynamic cps elegant after
looking at it a while. I know 'elegant' is not the first thing that comes to
mind when you have pb and rpc in the mix, but hey, can't keep it to myself.
I'm glad someone sees it that way :) It is at least consistent, if a little
verbose. I think it could be more "elegant" if we did a custom PB compiler
plugin and required service implementors to compile their endpoint definitions
with our own script or build target. Then I think we could control the
generated service method signatures. Maybe if I'm feeling especially crazy
I'll check that out over the holidays. But I wouldn't consider actually
shipping that unless it significantly simplified these cases and didn't require
additional mass changes.
bq. One thing I think we have lost though going to this new mechanism is the
ability to do generics: i.e. GenericProtocol over in hbase-server/src/test
can't be made work now. I believe this so because pb requires you specify a
type: https://developers.google.com/protocol-buffers/docs/proto#simple Do you
agree G?
Yes, I agree, though in a way generics don't even apply with the use of
protobufs. Services could do more dynamic interpretation of messages, but it
would be up to them to implement that in a way that made sense for the specific
case. I don't think there's anything we need to do to support this.
bq. How to do exceptions in a coprocessor? I see where we set the exception on
the controller if there is one, but should we then abandon further processing –
return? We need to call the RpcCallback done, though, right?
Yes, the exception should be set on the controller in order to be returned to
the client. It seems to be good practice to always call RpcCallback.done(),
but it's not strictly required for endpoint implementations and it should also
be fine to pass a null argument in the case of an exception. Your
implementation looks fine to me, assuming that "sum" is a required field in the
proto message, otherwise you could skip setting the dummy value in the response
on an exception.
One additional idea would be to define a custom unchecked exception
(EndpointException extends RuntimeException?) which we could watch for and use
to set the exception in the controller, but either with this or the current
ResponseConverter.setControllerException() we're relying on convention over a
real contract, which doesn't seem great.
> 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/RPC, master, migration, regionserver
> Reporter: Todd Lipcon
> Assignee: Gary Helmling
> Fix For: 0.96.0
>
> Attachments: HBASE-5448_2.patch, HBASE-5448_3.patch,
> HBASE-5448_4.patch, 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
