If v3 of the method emerges, we might need to retry twice, right ? Cheers
On Mon, Jul 30, 2012 at 8:09 PM, Jimmy Xiang <[email protected]> wrote: > 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. >
