After thinking about the pros and cons of the RFC solution and the
alternatives, taking into account the comments received, I have decided to move
it to the Icebox and not implement it for the time being.
Thanks all for the valuable feedback.
Best regards,
Alberto G.
Oh, but I forgot about WAN changes that may have been made to the handshake to
allow different versions in different clusters. Jake might be right about this.
On 2/2/21, 8:31 AM, "Bruce Schuchardt" wrote:
I think it's only the locator connections that do this. Regular
client->server
One thing that might help somewhat would be to modify the KnownVersion class to
hold both the product version and the client/server protocol version, which
wouldn't have to change if there are no incompatibilities introduced in
client/server comms in a release. That's more in keeping with what
I think it's only the locator connections that do this. Regular client->server
connections using the handshake code just send the client's current version,
which must not be newer than the server's version.
On 2/1/21, 9:53 AM, "Jacob Barrett" wrote:
Having just spent some time yanking
Having just spent some time yanking out some of the really really old version
support I think a naive version knocking approach would work. During the client
handshake the server will reject and close the connection of any client with a
newer version number than it supports. The client could
In my ideal world, the version represents the protocol version and not a
product release number. As Dan points out, we could add a negotiation option to
allow more flexibility between clients and servers.
To accomplish this we would need a simpler and well-specified protocol. The
current
Well, I have no objection to adding a system property for this if you want to
try it. Since those properties aren't technically part of the public API I
don't think we need to offer full support for what happens when the setting
breaks. I'm just thinking ahead to what will happen when the
Hi Dan,
Thanks a lot for your comments.
The scope of the RFC is not very ambitious. As I pointed out in it, the idea is
not to implement the backward compatibility of clients with older servers.
Rather, the aim is to allow to take advantage of the fact that serialization or
other types of
I think just sending the old version will only work until we actually make any
changes to the protocol. Once we do, serialization will break unless we also
change the client to pretend to be that old version, including the way it
serializes and deserializes messages. With this proposal there
Hi,
I have updated the proposal in the RFC by adding Patrick's suggestion (if I
have understood it correctly).
Best regards,
Alberto
From: Alberto Gomez
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSS] RFC - Add option
Thanks for your comments, Patrick.
Do you mean have the client always use in the handshake the oldest server
version it is compatible with?
Sounds like a reasonable simplification. In that case, I would use a flag to
activate this behavior so that the current behavior (the client sends the
It sounds like you intend to test which versions are compatible with each other
and maintain a list the client can use to reject the setting of force-version
when set to an incompatible version. If that’s the case, why not just have the
handshake look at that list and automatically connect with
Hi Geode devs,
I have just published the following RFC in the Geode wiki: "Add option to allow
newer Geode clients to connect to older Geode servers"
https://cwiki.apache.org/confluence/display/GEODE/Add+option+to+allow+newer+Geode+clients+to+connect+to+older+Geode+servers
Could you please
13 matches
Mail list logo
