hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Client-Server wire compatibility?
Date Thu, 05 Mar 2015 20:37:15 GMT
On Thu, Mar 5, 2015 at 12:24 PM, Stack <stack@duboce.net> wrote:

> On Thu, Mar 5, 2015 at 12:18 PM, lars hofhansl <larsh@apache.org> wrote:
>
> > Then we have broken server-server compatibility, which the doc state we
> > won't break for patch and minor versions.
>
> What is broke? A 1.1 client can't scan a 1.0 meta?
>

My thinking is that the fall-back approach would enable the new client code
to communicate with either server version. Kind of a poor-man's feature
negotiation protocol.

Can you elaborate Lars?

> -- Lars
> >       From: Andrey Stepachev <octo47@gmail.com>
> >  To: dev@hbase.apache.org
> >  Sent: Thursday, March 5, 2015 9:48 AM
> >  Subject: Re: Client-Server wire compatibility?
> >
> > Hi Nick,
> >
> > > I suppose it's possible the client in the master is never used outside
> of
> > localhost, I haven't checked that bit.
> >
> > Client is definitely used to access meta, which can be hosted anywhere,
> > so basically we can face with situation when master is upgraded and
> > hits old region server.
> >
> >
> >
> > On Thu, Mar 5, 2015 at 5:21 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
> >
> > > My point was that we cannot make this guarantee as there's a client
> > > embedded in the master (and perhaps other places). We can't enforce the
> > > order in which components are upgraded, which makes it possible for the
> > new
> > > client in the new master to reach out to an old RS during the rolling
> > > upgrade.
> > >
> > > I suppose it's possible the client in the master is never used outside
> of
> > > localhost, I haven't checked that bit.
> > >
> > > On Wednesday, March 4, 2015, lars hofhansl <larsh@apache.org> wrote:
> > >
> > > > The idea actually was that a new client can never be 100% supported,
> > > since
> > > > a user could use it accessing new features that the server does not
> > > > understand.The reverse is always possible, since the old client can
> > > expose
> > > > anything new unduly we can always upgrade the server as old as it
> > doesn't
> > > > break the old client.
> > > > Supporting both ways is too limiting I think, at least for minor
> > version.
> > > > For example we might want to add a *new* RPC.As long as we only
> support
> > > old
> > > > client with new servers we can do that. In any other combination that
> > > would
> > > > not (as easily) possible.
> > > > That's why I phrased it only that way in my version proposal.
> > > >
> > > > For patch releases it's reasonable to support it both ways.The book
> is
> > > > currently unavailable from the HBase site, so I can't check the exact
> > > > wording we ended up with.
> > > >
> > > > -- Lars
> > > >      From: Nick Dimiduk <ndimiduk@gmail.com <javascript:;>>
> > > >  To: hbase-dev <dev@hbase.apache.org <javascript:;>>
> > > >  Sent: Wednesday, March 4, 2015 4:49 PM
> > > >  Subject: Re: Client-Server wire compatibility?
> > > >
> > > > I believe your posted example is intended to be supported. There's no
> > > > enforcement, for instance, that the master is upgraded before all
> RS's.
> > > >
> > > >
> > > >
> > > > On Wed, Mar 4, 2015 at 4:06 PM, Matteo Bertozzi <
> > theo.bertozzi@gmail.com
> > > > <javascript:;>>
> > > > wrote:
> > > >
> > > > > the book (http://hbase.apache.org/book.html#hbase.versioning)
> > > > > talks about "only allow upgrading the server first" to use new
> APIs.
> > > > >
> > > > > what about a new client talking to an old server for "old"
> > operations?
> > > > > For example: If I have a 1.1 client, can I ask a 1.0 server to
> > create a
> > > > > table?
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Andrey.
> >
> >
> >
> >
>

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