You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2016/07/29 00:27:21 UTC

[jira] [Commented] (HBASE-16264) Figure how to deal with endpoints and shaded pb

    [ https://issues.apache.org/jira/browse/HBASE-16264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398495#comment-15398495 ] 

stack commented on HBASE-16264:
-------------------------------

See [~ghelmling] comment up in the parent issue: https://issues.apache.org/jira/browse/HBASE-15638?focusedCommentId=15386820&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15386820 Let me repeat it here:
{code}
For endpoints, the user will have:
# Created a .proto file with the service definition for their endpoint
# Run their own version of protoc to do the code gen for the service
# The generated PB messages for request/response, and, as you note, the RpcController and RpcCallback in the service method signatures will be in the com.google.protobuf package
# The endpoint jar is loaded in HBase
# The ServerRpcController we pass through for the endpoint invocation will extend our shaded RpcController
So the only way I see this working is if we force endpoint implementors to run a preprocessor step to shade the endpoint jar prior to step #4. Maybe that would work, but it seems pretty cumbersome. Or else we somehow avoid shading ServerRpcController.
{code}

Chatting w/ [~mbertozzi] on this issue, it is a painful one complicated by the fact that we'll have a pb2.5 jar on our CLASSPATH (because of HDFS and in particular because new AsyncWAL needs to pass HDFS HDFS-compat PBs). This pb2.5 jar occupies the com.google.protobuf slot on serverside at least. Non-shaded refs to c.g.protobug will be 2.5pb until HDFS does shading.

On client side, the problem is in our published public API in Table. It'd be ugly if these public APIs of a sudden were shaded, or at least, not w/o a means of transitioning current EPCPs (Endpoint Coprocessors) -- Gary's preprocessor step. Chatting w/ Matteo, let me try and leave the published APIs as unshaded and similar on Endpoint CP side. Let me see how far I get w/ this. Will probably crash and burn going from non-shaded to shaded but let me see. Could add new API to Table that wasn't PB-based for going forward. We'd probably need this anyways given c.g.pb is occupied by 2.5pb.

Fun, fun, fun!

> Figure how to deal with endpoints and shaded pb
> -----------------------------------------------
>
>                 Key: HBASE-16264
>                 URL: https://issues.apache.org/jira/browse/HBASE-16264
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Coprocessors, Protobufs
>            Reporter: stack
>            Assignee: stack
>
> Come up w/ a migration plan for coprocessor endpoints when our pb is shaded. Would be sweet if could make it so all just worked. At worst, come up w/ a prescription for how to migrate existing CPs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)