You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Bill Burcham (Jira)" <ji...@apache.org> on 2021/02/23 21:27:00 UTC

[jira] [Comment Edited] (GEODE-8963) separate client/server compatibility from server/server version compatibility

    [ https://issues.apache.org/jira/browse/GEODE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289346#comment-17289346 ] 

Bill Burcham edited comment on GEODE-8963 at 2/23/21, 9:26 PM:
---------------------------------------------------------------

[~onichols] One thing I can think of is that incrementing the server version ordinal (by more than one) for each minor release leaves "space" for the previous release's _patch versions_. Leaving the space lets us maintain the invariant that every release (.0,.1,etc) of a given minor release has a version ordinal that is _less than_ the version ordinal of every release of a "later" minor release.

Currently we have something like this (time progressing down the page):

{noformat}
version ordinal
1.13.0  120
1.13.1  121
1.14.0  125
1.13.2  122
1.14.1  126
{noformat}

If we didn't bump the ordinal at 1.14.0 what would we do if we needed a protocol change in 1.13.2? Would we say "no" to that protocol change?

There are problems with our current approach. What if more than four patches to 1.13.0 require version changes? If so we've used up our allotment. If we don't want to pre-allocate ordinal space like we do now, maybe we could think about a tree-structured version ordinal. Maybe instead of sending {{122}} on the wire we start sending {{"1.3.2"}}.


was (Author: bburcham):
[~onichols] One thing I can think of is that incrementing the server version ordinal (by more than one) for each minor release leaves "space" for the previous release's _patch versions_. Leaving the space lets us maintain the invariant that every release (.0,.1,etc) of a given minor release has a version ordinal that is _less than_ the version ordinal of every release of a "later" minor release.

Currently we have something like this (time progressing down the page):

{noformat}
1.13.0 120
1.13.1 121
1.14.0 125
1.13.2 122
1.14.1 126
{noformat}

If we didn't bump the ordinal at 1.14.0 what would we do if we needed a protocol change in 1.13.2? Would we say "no" to that protocol change?

There are problems with our current approach. What if more than four patches to 1.13.0 require version changes? If so we've used up our allotment. If we don't want to pre-allocate ordinal space like we do now, maybe we could think about a tree-structured version ordinal. Maybe instead of sending {{122}} on the wire we start sending {{"1.3.2"}}.

> separate client/server compatibility from server/server version compatibility
> -----------------------------------------------------------------------------
>
>                 Key: GEODE-8963
>                 URL: https://issues.apache.org/jira/browse/GEODE-8963
>             Project: Geode
>          Issue Type: Improvement
>          Components: serialization
>            Reporter: Bruce J Schuchardt
>            Assignee: Bruce J Schuchardt
>            Priority: Minor
>              Labels: pull-request-available
>
> A client's version is used for deserializing data received from the client and for serializing data sent to the client. It is also used to locate the map of Commands used to process client requests. Every time we cut a new release we bump this version in KnownVersions and create a new map of Commands, even though client/server communications protocols rarely change.
>  We should have each KnownVersion hold a client/server compatibility number that is used to identify clients rather than the KnownVersion's ordinal.
> For instance,
> {code:java}
>   public static final KnownVersion GEODE_1_15_0 =
>       new KnownVersion("GEODE", "1.15.0", (byte) 1, (byte) 15, (byte) 0, (byte) 0,
>           /*server/server version*/GEODE_1_15_0_ORDINAL, 
>           /*client/server version*/GEODE_1_15_0_ORDINAL);
>   
> public static final KnownVersion GEODE_1_16_0 =
>       new KnownVersion("GEODE", "1.16.0", (byte) 1, (byte) 16, (byte) 0, (byte) 0,
>           /*server/server version*/GEODE_1_16_0_ORDINAL, 
>           /*client/server version*/GEODE_1_15_0_ORDINAL);
> public static final KnownVersion GEODE_1_17_0 =
>       new KnownVersion("GEODE", "1.17.0", (byte) 1, (byte) 17, (byte) 0, (byte) 0,
>           /*server/server version*/GEODE_1_17_0_ORDINAL, 
>           /*client/server version*/GEODE_1_15_0_ORDINAL);
> {code}
> In the above KnownVersions the client/server serialization is known to have not changed since v1.15.0 and so there is no need to use a newer KnownVersion for clients.
> Client handshake code will need to be changed to use the client/server ordinal when identifying clients and servers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)