Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

While this assumption is valid for most scenarios and it facilitates the implementation of backward compatibility between clients and servers, there are scenarios in which it is required to be able to upgrade the clients before the servers during a rolling upgrade (for example in Kubernetes deployments) during a rolling upgrade.

Anti-Goals

This proposal does not intend to support the total backward compatibility between servers and clients in of Geode clients with any Geode server version.

Solution

A new configuration parameter may be added to the client so that, if used, the client would send a different Geode version during the handshake, in order to be able to communicate with servers in an older version with which it is compatible.

Two alternatives for this new configuration parameter are proposed:

  • A new optional numeric System Property

...

  • could be used by the Geode Java client to set the version used by it in the handshake with a server. With this property, a Geode Java client in version X could advertise itself towards a server, during the handshake, as being in version Y (Y being older than X) to allow to connect to a server in version Y or older.

In case a client version is incompatible with an older server version, the client should reject the setting of that version in the new System Property proposed.

For example, in order for a client using version 1.15 of the Geode Java API to connect to a server in version 1.14, the client would be required to use the following system property:

-Dgemfire.forced-client-version=125
  • A new optional boolean System Property could be used by the Geode Java client so that, if used, the client would send in the handshake the oldest Geode server version compatible with this client.

For example, in order for a client using version 1.15 of the Geode Java API to connect to a server in version 1.12, the client would be required to use the following system property:

-Dgemfire.backward-compatible-client

In this case, assuming that the oldest Geode server compatible with a client in version 1.15 is 1.9.0, the client will send in the handshake the 1.9.0 version. Consequently, a client using version 1.15 would not be able to communicate with a server in version 1.8 or older even if it used this parameter.

The use of any of these parametersThis parameter, by itself, will not guarantee the compatibility between the client and the server but . Nevertheless, incompatibilities (specially between minor releases) are very rare so, in the general case, no changes will be required in the client to support backward compatibility.

In case a newer client version is incompatible with an older server version, the client should reject the setting of that version in the new System Property proposed.In order to have certainty about the compatibility between versions, test cases would be added to verify the correct behavior of newer clients using this new parameter connecting to older servers or the incompatibility between clients and servers.

...

A new system property will be added to Geode (-Dgemfire.forced-client-version or -Dgemfire.backward-compatible-client depending on the option selected) that will allow to set change the ordinal of the Geode version to be sent by the client to the server during the handshake.

...