Bruce,
>> To solve that problem we currently have to issue a new 1.13 release that
>> knows about v1.12.1 and users have to roll their servers to the new v1.13.1.
Even if we introduce the client protocol version, the users still need to
upgrade to server version, that understands the protocol right? E.g. 1.13 may
not understand 1.8.1 (or 1.9) protocol.
Also, currently we have client and server versions; this will introduce one
more versioning requirement (with respect to client/server messaging protocol);
I am just wondering will there be any additional work/complexities in knowing,
maintaining client/server version and the messaging protocol version with
them...
-Anil.
On 2/23/21, 1:56 PM, "Dan Smith" <dasm...@vmware.com> wrote:
Ha, I was thinking of suggesting this when I saw Alberto's earlier
proposal. This does seem like a good idea to only bump the client version when
the protocol actually changes.
One concern is that it might not be obvious that changing a
DataSerializableFixedId will change the client protocol. Some objects get sent
or received from the client and some don't, but we don't have a clear
indication which is which. Is there some way that we could know when changing a
DataSerializableFixedId if it is involved in the client protocol or not?
I also wonder if this will affect the WAN - do we want to keep sending the
current product version with the WAN, or use the client protocol version?
-Dan
________________________________
From: Bruce Schuchardt <bru...@vmware.com>
Sent: Tuesday, February 23, 2021 9:38 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: [DISCUSS] client/server communications and versioning
I’m considering a change in client/server communications that I would like
feedback on.
We haven’t changed on-wire client/server communications since v1.8 yet we
tie these communications to the current version. The support/1.14 branch
identifies clients as needing v1.14 for serialization/deserialization, for
instance, even though nothing has changed in years.
If we put out a patch release, say v1.12.1, clients running that patch
version cannot communicate with servers running v1.12.0. They also can’t
communicate with a server running v1.13.0 because that server doesn’t know
anything about v1.12.1 and will reject the client. To solve that problem we
currently have to issue a new 1.13 release that knows about v1.12.1 and users
have to roll their servers to the new v1.13.1.
I propose to change this so that the client’s on-wire version is decoupled
from the “current version”. A client can be running v1.14.0 but could use
v1.8.0 as its protocol version for communications.
This would have an impact on contributors to the project. If you need to
change the client/server protocol version you will need to modify
KnownVersion.java to specify the change, and should let everyone know about the
change.
See
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&data=04%7C01%7Cagingade%40vmware.com%7Cb2798fe5be1a401bfa5708d8d845ea70%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637497142090368767%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9Tr2x%2BWD3s43TvoQNtsyqW0rwhNU5GOK8PxxEjw1mb8%3D&reserved=0
