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 2020/06/16 21:07:00 UTC
[jira] [Comment Edited] (GEODE-8240) View has old locator version
number after rolling upgrade
[ 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)