[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8240:
--------------------------------
Description:
as shown in [https://github.com/apache/geode/pull/5224]
locator upgrade from version 1.12.0 doesn't seem to occur
{{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 problem was introduced in 1.12.0 and is present in all lines derived from
that one, including 9.10, 1.13, and current develop/1.14
What's actually happening is that the locator _is_ upgraded to a newer version.
It joins with an older coordinator (that's running e.g. 1.12.0) and that
coordinator produces a view showing the new locator/member as running the same
version, in this case 1.12.0, as the coordinator.
Eventually, all locators will be upgraded. But the view carries the incorrect
version indication.
The root cause seems to be that when {{GMSMemberData.setVersionObject(short
versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
ordinal corresponding to a new line of development: 1.13, 1.14, … that method
throws away that version ordinal and replaces it with the one for the 1.12 line.
Since the current {{support/1.13}} and {{develop}} branches have the bug
upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
exhibit the same behavior (locator apparently stuck at the older version in the
view.)
Ramifications of this incorrect version indication in the view are TBD.
Whether or not this situation resolves itself after _another_ round of restarts
is TBD.
was:
as shown in [https://github.com/apache/geode/pull/5224]
locator upgrade from version 1.12.0 doesn't seem to occur
{{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 problem was introduced in 1.12.0 and is present in all lines derived from
that one, including 9.10, 1.13, and current develop/1.14
What's actually happening is that the locator _is_ upgraded to a newer version.
It joins with an older coordinator (that's running e.g. 1.12.0) and that
coordinator produces a view showing the new locator/member as running the same
version, in this case 1.12.0, as the coordinator.
Eventually, all locators will be upgraded. But the view carries the incorrect
version indication.
The root cause seems to be that when {{GMSMemberData.
Ramifications of this incorrect version indication in the view are TBD.
Whether or not this situation resolves itself after _another_ round of restarts
is TBD.
> 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]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{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 problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
