[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148090#comment-17148090
]
ASF GitHub Bot commented on GEODE-8240:
---------------------------------------
Bill commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r446354173
##########
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
##########
@@ -549,7 +550,7 @@ public void setVersionObjectForTest(Version v) {
}
@Override
- public Version getVersionObject() {
+ public VersionOrdinal getVersionObject() {
Review comment:
Since `IDM` isa `MemberIdentifier` this (overridden) method has to
return a `VersionOrdinal` not a `Version` since, in general, a
`MemberIdentifier` can be for a member that is running an unknown software
version.
I'm renaming `MemberIdentifier.getVersionObject()` =>
`MemberIdentifier.getVersionOrdinalObject()`.
To summarize the state of `IDM` version methods this is what it looks like
now:
```java
// inherited from MemberIdentifier. It has a new name to make the return
type explicit
@Override
public VersionOrdinal getVersionOrdinalObject() {…}
/**
* If this member runs a version known in this JVM then return that
Version.
* If this member does not run a known version then return Version.CURRENT.
*
* In various serialization scenarios we want the well-known version for
this
* member, or, if it doesn't have a well-known version, we want the current
* (in this JVM) software version. Rather than have that logic spread
around in
* the serialization code, it is centralized here.
*/
public Version getVersionObject() {…}
```
We still have lots of ways to get a `Version` from a `short` version
ordinal. `Version` class has these static methods:
* `fromOrdinal(short ordinal) throws
UnsupportedSerializationVersionException`
* `fromOrdinalOrCurrent(short ordinal)`
* `fromOrdinalNoThrow(short ordinal, boolean returnNullForCurrent)`
There is some unfortunate duplication in those methods. Consolidating that
logic is beyond the scope of this PR.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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)
