Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Handling protocol versions

Copy link to this message
Re: Handling protocol versions
On Thu, Dec 27, 2012 at 7:11 PM, Stack <[EMAIL PROTECTED]> wrote:

>  Not knowing much about the recent changes, why don't we go full PB, and
>> define actual rpc methods as services? (as in
>> https://developers.google.com/protocol-buffers/docs/proto#services)
> I thought about it.  It has some nice facility that comes for free.  For
> example, you can get an aforementioned pb'd description of the "protocol"
> and actually used the return to compose an invocation against the server.
>  Nice.  Our 'protocols' actually already implement Service.Interface from
> pb (actually Service.BlockingInterface).  I'm not sure why as it looks to
> complicate things going by a quick examination today (I started stripping
> it out to see what would break).  So it would not take too much to get a
> Stub on clientside and have servers implement the Service.  We could try
> shoehorning our RPC so it implemented the necessary RpcController, etc.
> Interfaces.
> But it would seem Service is deprecated with a good while now [1] and
> folks are encouraged to do otherwise because as is, the generated code
> makes for too much "indirection" [1].
> I could try playing around some more w/ using Service to learn more about
> this 'indirection'.  We could use the long-hand service descriptor in place
> of the above suggested bitmap figuring what the server provides.
I experimented hooking up protobuf Service to our RPC.  I put up a patch
over on https://issues.apache.org/jira/browse/HBASE-6521 along w/ some
notes made while messing.

The main 'pro' is that our rpc would get a much needed spring cleaning.
 Main 'con' is that we would be changing code (smile).  The main TODO is
making sure no performance degradation (should be none server-side, need to
make sure same is true client-side).

This experiment has made me change my opinion regards 'versioning'.  Above
I suggest we remove VersionedProtocol and add in instead a protobuf
ProtocolDescriptor that would have a 'version' as well as a short and long
form description of server 'features'.  Now I think we should just punt on
version/descriptors altogether.  Lets just go the route where a method is
supported or not.  That methods take a protobuf request and returns a
protobuf response, as has been said already, gives us some wriggle room to
evolve methods as time goes by.  For protocol migrations that require more
this 'vocabulary', lets deal w/ them on a case by case basis (As per Enis