I looked at TestMultipleProtocolServer.java from hadoop trunk. It illustrates how VersionedProtocol is used for client to talk to servers running various versioned protocols.
FYI On Mon, Jul 30, 2012 at 8:11 PM, Ted Yu <[email protected]> wrote: > 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. >> > >
