hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Handling protocol versions
Date Tue, 31 Jul 2012 03:11:44 GMT
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 <jxiang@cloudera.com> 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 <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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message