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
Copy link to this message
-
Re: Handling protocol versions
Another approach is to use the new call at first.  If got some
exception like unknown method, then fall back to the old method.

Thanks,
Jimmy

On Mon, Jul 30, 2012 at 5:47 PM, Devaraj Das <[EMAIL PROTECTED]> wrote:
> Wondering whether we should retain the VersionedProtocol now that we have protobuf implementation for most (all?) of the protocols. I think we still need the version checks and do them when we need to. Take this case:
> 1. Protocol Foo has as one of the methods FooMethod(FooMethodRequest).
> 2. Protocol Foo evolves over time, and the FooMethod(FooMethodRequest) now has a better implementation called FooMethod_improved(FooMethodRequest).
> 3. HBase installations have happened with both the protocol implementations.
> 4. Clients should be able to talk to both old and new servers (and invoke the newer implementation of FooMethod if the protocol implements it).
>
> (4) is possible when the getProtocolVersion is implemented by the protocol at the server. The client could check what the version of the protocol was (assuming VersionedProtocol semantics where the protocol version number is upgraded for such significant changes) and depending on that invoke the appropriate method...
>
> Having to map version-numbers of protocols to the methods-supported is probably arcane IMO but works..
>
> The other approach (that wouldn't require the version#) is to do something like - On the client side, get the protocol methods supported at the server (and cache it) and then look this map up whenever needed to decide which method to invoke.
>
> Any thoughts on whether we should invest time in the second approach yet?
>
> Thanks,
> Devaraj.
+
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
+
Stack 2013-01-02, 00:44
+
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