I like the idea of "getServerCapabilities()" as a bitset. - Andy
On Wed, Aug 1, 2012 at 11:04 AM, Todd Lipcon <t...@cloudera.com> wrote: > One possibility: > > During the IPC handshake, we could send the full version string / > source checksum. Then, have a client-wide map which caches which > methods have been found to be supported or not supported for an > individual version. So, we don't need to maintain the mapping > ourselves, but we also wouldn't need to do the full retry every time. > > A different idea would be to introduce a call like > "getServerCapabilities()" which returns a bitmap, and define a bit per > time that we add a new feature. > > The advantage of these approaches vs a single increasing version > number is that we sometimes want to backport a new IPC to an older > version, but not backport all of the intervening IPCs. Having a bitmap > allows us to "pick and choose" on backports without having to pull in > a bunch of things we didn't necessarily want. > > -Todd > > On Wed, Aug 1, 2012 at 1:41 AM, Stack <st...@duboce.net> wrote: >> On Tue, Jul 31, 2012 at 1:47 AM, Devaraj Das <d...@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? >>> >> >> The VersionedProtocol w/ client being able to interrogate what methods >> a server supports strikes me as a facility that will be rarely used if >> at all and bringing it along, keeping up the directory of supported >> methods, will take a load of work on our part that we'll do less than >> perfectly so should it ever be needed, it won't work because we let it >> go stale. >> >> What do you reckon? >> >> The above painted scenario too is a little on the exotic side. We can >> do something like Jimmy suggests in those rare cases we need to add a >> new method because there is insufficient wiggle-room w/i the >> particular PB method call (If we get into the issue Ted raises where >> we'd have to go back to the server twice because there is a third new >> method call, we're doing our API wrong). >> >> The protocol needs a version though. We'll be still sending that >> 'hrpc' long in the header preamble? Should we add a version long >> after the 'hrpc' long? >> >> As to a directory of supported methods, do we need this in the >> protocol at all? Can't this be knowledge kept outside of the >> on-the-wire back and forth? >> >> St.Ack > > > > -- > Todd Lipcon > Software Engineer, Cloudera -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
