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
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.
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