hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jimmy Xiang <jxi...@cloudera.com>
Subject Re: Handling protocol versions
Date Tue, 31 Jul 2012 03:09:49 GMT
Another approach is to use the new call at first.  If got some
exception like unknown method, then fall back to the old method.


On Mon, Jul 30, 2012 at 5:47 PM, Devaraj Das <ddas@hortonworks.com> 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.

View raw message