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 Plain View
HBase >> mail # dev >> Handling protocol versions


+
Devaraj Das 2012-07-31, 00:47
+
Jimmy Xiang 2012-07-31, 03:09
+
Ted Yu 2012-07-31, 03:11
+
Ted Yu 2012-07-31, 21:50
+
Stack 2012-08-01, 08:41
+
Todd Lipcon 2012-08-01, 18:04
+
Andrew Purtell 2012-08-01, 19:39
+
Devaraj Das 2012-08-03, 18:40
+
Stack 2012-12-27, 20:05
+
Jimmy Xiang 2012-12-27, 21:13
+
Enis Söztutar 2012-12-28, 01:37
+
Stack 2012-12-28, 03:11
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
+
Elliott Clark 2013-01-02, 22:34
+
Stack 2013-01-07, 21:15
+
Devaraj Das 2012-12-28, 09:31
+
Stack 2012-12-28, 16:59
+
Devaraj Das 2012-12-28, 17:22
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