[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17137918#comment-17137918
]
Bill Burcham edited comment on GEODE-8240 at 6/16/20, 9:06 PM:
---------------------------------------------------------------
I have a theory that maybe this commit from January, 2020, that went into
1.12.0:
https://github.com/apache/geode/commit/40d6b47ffce96df1e1bc0da88dff661b57939d7e
Which changed {{GMSMemberData.setVersionOrdinal(short)}} to call the new
{{GMSMemberData.setVersionObject(short)}}:
{code}
private void setVersionObject(short versionOrdinal) {
try {
this.versionObj = Version.fromOrdinal(versionOrdinal);
} catch (UnsupportedSerializationVersionException e) {
this.versionObj = Version.CURRENT;
}
}
{code}
That method is causing the {{versionObj}} member to be set to
{{Version.CURRENT}} if the ordinal we attempt to set is unknown e.g. a newer
version. If I'm right then with that method in place, any time a
{{GMSMemberData}} is constructed from data serialized from a newer product
version, the version will get "clamped" to the current product version.
That commit was first introduced into Geode 1.12.0.
Before that commit, the member was {{versionOrdinal}} and was set directly from
the {{short}} argument—it was not validated through
{{Version.fromOrdinal(versionOrdinal)}}
I'm thinking to test this maybe I check out the 1.12 released version
https://github.com/apache/geode/tree/rel/v1.12.0 and build it with a fix and
deploy that to my local maven repo and make my DUnit upgrade test (for current
{{develop}}) use that 1.12.x version.
was (Author: bburcham):
I have a theory that maybe this commit from January, 2020, that went into
1.12.0:
https://github.com/apache/geode/commit/40d6b47ffce96df1e1bc0da88dff661b57939d7e
Which changed {{GMSMemberData.setVersionOrdinal(short)}} to call the new
{{GMSMemberData.setVersionObject(short)}}:
{code}
private void setVersionObject(short versionOrdinal) {
try {
this.versionObj = Version.fromOrdinal(versionOrdinal);
} catch (UnsupportedSerializationVersionException e) {
this.versionObj = Version.CURRENT;
}
}
{code}
That method is causing the {{versionObj}} member to be set to
{{Version.CURRENT}} if the ordinal we attempt to set is unknown e.g. a newer
version. If I'm right then with that method in place, any time a
{{GMSMemberData}} is constructed from data serialized from a newer product
version, the version will get "clamped" to the current product version.
That commit was first introduced into Geode 1.12.0.
> View has old locator version number after rolling upgrade
> ---------------------------------------------------------
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
> Reporter: Ernest Burghardt
> Assignee: Bill Burcham
> Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>
> upgrade from version 1.12 doesn't seem to occur on the Locator
>
> testRollServersOnPartitionedRegion_dataserializable failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> ---- |
> -------------------------------------------------------------------------------
> vm2 | 127.0.0.1(vm2:35019:locator)<ec><v17>:41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025)<v27>:41001
> vm1 | 10.0.0.111(vm1:35030)<v29>:41002
> ">
> not to contain:
> <"1.12.0">
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
