[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148178#comment-17148178
]
ASF GitHub Bot commented on GEODE-8240:
---------------------------------------
bschuchardt commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r447282170
##########
File path:
geode-serialization/src/main/java/org/apache/geode/internal/serialization/VersionOrdinal.java
##########
@@ -0,0 +1,83 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.internal.serialization;
+
+/**
+ * VersionOrdinal is able to represent not only currently-known
+ * Geode versions but future versions as well. This is necessary
+ * because during rolling upgrades Geode manipulates member
+ * identifiers for members running newer versions of the software.
+ * In that case we receive the ordinal over the network
+ * (serialization) but we don't know other version details such as
+ * major/minor/patch version, which are known to the Version class.
+ *
+ * Implementations must define equals() and hashCode() based on
+ * ordinal() result. And since this interface extends Comparable,
+ * implementations must define compareTo() as well.
+ *
+ * Unlike Version (a subtype of VersionOrdinal which acts like an
+ * enumerated type), VersionOrdinal does not, in general, guarantee
+ * that if vo1.equals(vo2) then vo1 == vo2.
+ *
+ * Use the Versioning factory class to construct objects implementing
+ * this interface. All instances of known versions are defined as
+ * constants in the Version class, e.g. Version.GEODE_1_11_0
+ */
+public interface VersionOrdinal extends Comparable<VersionOrdinal> {
Review comment:
VersionOrdinal's methods should take VersionOrdinal arguments.
----------------------------------------------------------------
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)
