[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146394#comment-17146394
]
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_r446240838
##########
File path:
geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientSideHandshakeImpl.java
##########
@@ -270,7 +271,7 @@ public ServerQueueStatus handshakeWithServer(Connection
conn, ServerLocation loc
private InternalDistributedMember readServerMember(DataInputStream p_dis)
throws IOException {
byte[] memberBytes = DataSerializer.readByteArray(p_dis);
- Version v = StaticSerialization.getVersionForDataStreamOrNull(p_dis);
+ final VersionOrdinal v =
StaticSerialization.getVersionForDataStreamOrNull(p_dis);
Review comment:
This should continue to use Version, not VersionOrdinal. Using Version
ensures that we never create a datastream with an unknown ordinal. None of our
serialization code will know what to do if that should happen.
##########
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:
This should continue to return a Version, not a VersionOrdinal. We
already have a method for getting the ordinal.
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/HeapDataOutputStream.java
##########
@@ -48,7 +49,7 @@
org.apache.geode.internal.serialization.BufferDataOutputStream
implements ObjToByteArraySerializer, ByteBufferWriter {
- public HeapDataOutputStream(Version version) {
+ public HeapDataOutputStream(VersionOrdinal version) {
Review comment:
same comment about retaining the use of Version in all serialization
code. We need assurance in place that we will never encounter an unknown
ordinal during serialization/deserialization.
##########
File path:
geode-serialization/src/main/java/org/apache/geode/internal/serialization/VersionOrdinalImpl.java
##########
@@ -0,0 +1,132 @@
+/*
+ * 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;
+
+public class VersionOrdinalImpl implements VersionOrdinal {
+
+ protected final short ordinal;
+
+ public VersionOrdinalImpl(final short ordinal) {
+ this.ordinal = ordinal;
+ }
+
+ @Override
+ public short ordinal() {
+ return ordinal;
+ }
+
+ @Override
+ public int compareTo(final VersionOrdinal other) {
+ if (other == null) {
+ return 1;
+ } else {
+ return compareTo(other.ordinal());
+ }
+ }
+
+ /**
+ * TODO: eliminate this legacy method in favor of requiring callers to
construct a
+ * VersionOrdinalImpl. Inline this logic up in compareTo(VersionOrdinal).
+ */
+ public int compareTo(final short other) {
+ // short min/max can't overflow int, so use (a-b)
+ final int thisOrdinal = this.ordinal;
+ final int otherOrdinal = other;
+ return thisOrdinal - otherOrdinal;
+ }
+
+ @Override
+ public boolean equals(final Object other) {
+ if (other == this)
+ return true;
+ if (other instanceof VersionOrdinalImpl) {
+ return this.ordinal == ((VersionOrdinalImpl) other).ordinal;
+ } else {
+ return false;
+ }
+ }
+
+ public boolean equals(final VersionOrdinal other) {
+ return other != null && this.ordinal == other.ordinal();
+ }
+
+ @Override
+ public int hashCode() {
+ int result = 17;
+ final int mult = 37;
+ result = mult * result + this.ordinal;
+ return result;
+ }
+
+ @Override
+ public String toString() {
+ return toString(ordinal);
+ }
+
+ /**
+ * TODO: eliminate this legacy method in favor of requiring callers to
construct a
+ * VersionOrdinalImpl. Inline this logic up in toString().
+ */
+ public static String toString(short ordinal) {
+ return "UNKNOWN[ordinal=" + ordinal + ']';
Review comment:
could this find the name of a Version and use it? Alternatively just
use "VersionOrdinal" instead of "UNKNOWN"
##########
File path:
geode-core/src/integrationTest/resources/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt
##########
@@ -578,9 +502,6 @@ org/apache/geode/internal/admin/remote/LicenseInfoResponse,2
fromData,18
toData,15
-org/apache/geode/internal/admin/remote/MissingPersistentIDsRequest,1
Review comment:
this removal of MissingPersistentIDsRequest surprised me. The class
still exists in my checkout and is a DSFID.
----------------------------------------------------------------
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)
