Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
above).

St.Ack
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB