ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Introducing "compatibility level" concept.
Date Wed, 30 Sep 2015 08:12:23 GMT

I see you point, but I do not see how we can implement it in our
distributed environment. Very weird situations could appear. E.g. if there
are two versions A and B:
1) Node A starts.
2) Node B starts and agrees with A to use old A-protocol.
3) Some data is persisted on disk using A-protocol;
4) Cluster shuts down.
5) Several new B-nodes appear, but have no clue that something was
persisted using A-protocol. They decide to use B-protocol.
6) Node A restarts and meets unknown B-protocol.

On Wed, Sep 30, 2015 at 11:01 AM, Branko ─îibej <brane@apache.org> wrote:

> On 30.09.2015 09:51, Vladimir Ozerov wrote:
> > Igniters,
> >
> > Normally we are trying to maintain backward compatibility with previous
> > versions. But it is not always possible.
> >
> > E.g. we are about to release portable protocol. There are lots
> suggestions
> > how to optimize it, but all of them are relatively hard to implement. It
> > would not be a problem if are able to improve it iteratively from release
> > to release while still allowing for different versions (e.g. 1.5 and 1.6)
> > to communicate.
> >
> > What if we add a top-level property "*compatibility level*" allowing user
> > to "downgrade" some parts of the system to communicate with earlier
> > versions?
> That's likely to be a huge pain to maintain. The problem is that it
> doesn't force you to think about compatibility too much, and you'll end
> up having any number of incompatible protocols that you'll have to
> maintain simultaneously.
> There's an IMO better way: define the protocol to be natrually
> extensible, and introduce a capability exchange step. Map protocol
> extensions to capabilities (these can represented as simple tokens, or
> whatever), then make the client and server use any capabilities that are
> common to both.
> We do this in Subversion; that's how a 1.9 server can work with a 1.0
> client but the same server will work much better (with more features
> available) with a 1.9 client. And the other way around, of course.
> -- Brane

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