Rolling upgrade is only supported for Geode v1.0 and up. Rolling from GemFire
8 isn't supported due to the JGroups upgrade.
On 3/10/21, 10:37 AM, "Bill Burcham" <bill.burc...@gmail.com> wrote:
Jakov, VersionRequest/VersionResponse is understood by the 8.1.x/GFE_81
product versions.
I don't know what Geode's stance is on supporting old locator versions. I
see the recent:
GEODE-8837 - Establishes GFE_81 as the oldest supported client.
Does that imply that GFE_81 is now the oldest supported version for
locators in rolling upgrade too? Seems reasonable to me. What do others
think?
On Tue, Mar 9, 2021 at 12:37 AM Jakov Varenina <jakov.varen...@est.tech>
wrote:
> Hi community,
>
> I have one question regarding VersionRequest/VersionResponse messages.
>
> Before member sends actual message, it has to first determine the remote
> member version. This is done by exchanging
> /VersionRequest///VersionResponse/ messages using function
> /getServerVersion() /from class /TcpClient.java/. There is part of code
> in /getServerVersion()/ for which I'm unsure which case is actually
> covering:
>
>
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2F854456c81ca7b9545eba252b6fa075318bb33af8%2Fgeode-tcp-server%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Fdistributed%2Finternal%2Ftcpserver%2FTcpClient.java%23L289&data=04%7C01%7Cbruces%40vmware.com%7C5b82c9992ccc4a75da8008d8e3f39254%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637509982565124714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AJsl8YYEqvt%2BFGFPKAAY2yRNIoezZZR4OalzAuW7wQk%3D&reserved=0
>
>
> try {
> final Object readObject =objectDeserializer.readObject(versionedIn); if
> (!(readObjectinstanceof VersionResponse)) {
> throw new IllegalThreadStateException(
> "Server version response invalid: This could be the result of
> trying to
> connect a non-SSL-enabled client to an SSL-enabled locator."); }
>
> final VersionResponse response = (VersionResponse) readObject;
> serverVersion = response.getVersionOrdinal(); serverVersions.put(address,
> serverVersion); return serverVersion; }catch (EOFException ex) {
> // old locators will not recognize the version request and will close
> the connection }
> ...
> return KnownVersion.OLDEST.ordinal();
>
> The case is when /readObject()/ try to read /VersionResponse/ and then
> throws /EOFException/. As you can see, there is comment in catch
> statement explaining the case, but I'm not sure that I understand it
> correctly. What I assume is that member with old version (less or equal
> to /KnownVersion.OLDEST/) of Geode does not support /VersionRequest/
> message, and will close connection if receive such message. This will
> result with /EOFException/ on remote member that sent /VersionRequest/.
> Is this correct understanding? Is this case still valid with the latest
> non-deprecated version set to /GFE_81/?
>
> The reason why I'm asking this is because in some cases in kuberentes
> cluster, it is possible to get /EOFException/ when remote member is not
> yet accessible. In this case member will still try to send message (e.g.
> /RemoteLocatorJoinRequest/) thinking that it is old member on the other
> side, and that will then result with /ClassCastException/ when reading
> response (e.g. /RemoteLocatorJoinResponse/).
>
> BRs,
>
> Jakov
>
>
