Canceled: apache/geode-native#2992 (develop - bddc86b)

[Travis CI]

Build Update for apache/geode-native
-

Build: #2992
Status: Canceled

Duration: ?
Commit: bddc86b (develop)
Author: Blake Bender
Message: GEODE-8902: parse server destroy reply in gnmsg (#739)

* Parse REPLY from server for DESTROY message
- Reading flags, version tag, and entry not found parts
- still need to decode "bytes" part

* Parse remaining ("OkBytes") part of message
- one byte, value 0, should be all we find here
- comment in server code says this is here to "make old single-hop code
  happy"

View the changeset: 
https://github.com/apache/geode-native/compare/a467cdefdcb6...bddc86b7364e

View the full build log and details: 
https://travis-ci.com/github/apache/geode-native/builds/215849380?utm_medium=notification_source=email

  Restart your build: 
https://travis-ci.com/github/apache/geode-native/builds/215849380?utm_medium=notification_source=email

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807653_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Bruce Schuchardt]

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 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 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 use this 
as signal to downgrade its version and try again. This could continue until the 
server accepts the client. We would need to decide if we would expect the 
entire membership to be a the same versions or if the version knocking needs to 
be on a per member basis. Obviously knocking for every connection is not ideal 
so some sort heuristic should be maintained for the life of the client.

Interestingly enough the clients sort of did this up until the merge of 
this version cleanups. All clients first made connections using the very old 
protocol version so that the server would send its version back. Then the 
client would disconnect and reconnect using its current version. The same could 
be done today with the current protocol version, the clients could make first 
connection with v1.0.0, get the server version, close and reconnect identifying 
themselves at the same server version.

-Jake


On Jan 29, 2021, at 3:35 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:

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 protocol 
does change. At that point setting the system property will not work, unless 
the client has the capability to negotiate and discover the server version and 
use the old protocol the way that WAN does.

Do keep in mind that failures may not be obvious if the serialization 
protocol changes and your client is pretending to be a different version. I 
think it's possible that the errors might show up only in log messages or 
corrupted values, and only if you are using whatever features are affected by a 
protocol change.

-Dan

From: Alberto Gomez 
mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to 
connect to older Geode servers

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 changes that may break this compatibility are 
not very frequent. For those cases where there have been no incompatible 
changes, with one of the proposed System Properties, it would be possible for a 
client to communicate with an older compatible server without the need of 
implementing anything extra. And we would have the test cases in place to 
assure this. For those cases where compatibility has been broken, it will not 
be possible to communicate the client with the older server and we would also 
have the tests showing that this communication is not possible even if the 
proposed System Property is used.

I do not know how costly it would be to implement and maintain the 
alternative approach you suggest with the negotiation required to support full 
backward compatibility. I would leave that to a different RFC. The good thing 
is that the current RFC could serve as a first step to implement the second, if 
it is agreed that this second feature is worth of being put in Geode.

Best regards,

Alberto

From: Dan Smith mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to 
connect to older Geode servers

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. 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Bruce Schuchardt]

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 Alberto is 
suggesting and is something we did in a past project (pre-Geode, pre-Pivotal) 
that never made it into the dev branch.

You could still have the downgrade behavior that Jake described but you 
wouldn't have to do it as often since, as Alberto pointed out, we rarely 
introduce incompatibilities these days.

In the case where the client/server protocol version hasn't changed but the 
client has a newer version than the server the client could use the server's 
older version for serialization.  The client would have to avoid using some 
client-side features added in its newer release, which I doubt would be an 
issue if we're just talking about rolling to a new version of Geode.

It's not the ideal world that Anthony envisions but it's a step that wouldn't 
take much work.

On 2/1/21, 9:27 AM, "Anthony Baker"  wrote:

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 protocol is pretty gnarly and difficult to piece together from the 
implementation.  Complicating this is the fact that the protocol includes not 
only the message definitions but also the data serialization mechanisms for any 
data type included in a message.  Given the challenge of answering “has any 
message or serialization changed?” we've taken the route of using release 
versions.  Perhaps we could build an automated analysis tool that could answer 
this question and reduce frequency of version bumps to match when something 
_really_ changes.

While some work has been done in this direction [1], it’s not far enough 
along to be a viable alternative as yet.

Anthony

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FNew%2BClient%2BServer%2BProtocoldata=04%7C01%7Cbruces%40vmware.com%7C87d10a873f5c4105ab6a08d8c6d696d2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477972248729037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hsWyivHYUmQhtortUac9qqJlqkgpuHzNIXM42Nlsg1Y%3Dreserved=0



On Jan 29, 2021, at 3:35 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:

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 protocol does 
change. At that point setting the system property will not work, unless the 
client has the capability to negotiate and discover the server version and use 
the old protocol the way that WAN does.

Do keep in mind that failures may not be obvious if the serialization 
protocol changes and your client is pretending to be a different version. I 
think it's possible that the errors might show up only in log messages or 
corrupted values, and only if you are using whatever features are affected by a 
protocol change.

-Dan

From: Alberto Gomez mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to 
connect to older Geode servers

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 changes that may break this compatibility are 
not very frequent. For those cases where there have been no incompatible 
changes, with one of the proposed System Properties, it would be possible for a 
client to communicate with an older compatible server without the need of 
implementing anything extra. And we would have the test cases in place to 
assure this. For those cases where compatibility has been broken, it will not 
be possible to communicate the client with the older server and we would also 
have the tests showing that this communication is not possible even if the 
proposed System Property is used.

I do not know how costly it would be to implement and maintain the 
alternative approach you suggest with the negotiation required to support full 
backward compatibility. I would leave that to a different RFC. The good 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Bruce Schuchardt]

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 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 use this 
as signal to downgrade its version and try again. This could continue until the 
server accepts the client. We would need to decide if we would expect the 
entire membership to be a the same versions or if the version knocking needs to 
be on a per member basis. Obviously knocking for every connection is not ideal 
so some sort heuristic should be maintained for the life of the client.

Interestingly enough the clients sort of did this up until the merge of 
this version cleanups. All clients first made connections using the very old 
protocol version so that the server would send its version back. Then the 
client would disconnect and reconnect using its current version. The same could 
be done today with the current protocol version, the clients could make first 
connection with v1.0.0, get the server version, close and reconnect identifying 
themselves at the same server version.

-Jake


On Jan 29, 2021, at 3:35 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:

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 protocol does 
change. At that point setting the system property will not work, unless the 
client has the capability to negotiate and discover the server version and use 
the old protocol the way that WAN does.

Do keep in mind that failures may not be obvious if the serialization 
protocol changes and your client is pretending to be a different version. I 
think it's possible that the errors might show up only in log messages or 
corrupted values, and only if you are using whatever features are affected by a 
protocol change.

-Dan

From: Alberto Gomez mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to 
connect to older Geode servers

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 changes that may break this compatibility are 
not very frequent. For those cases where there have been no incompatible 
changes, with one of the proposed System Properties, it would be possible for a 
client to communicate with an older compatible server without the need of 
implementing anything extra. And we would have the test cases in place to 
assure this. For those cases where compatibility has been broken, it will not 
be possible to communicate the client with the older server and we would also 
have the tests showing that this communication is not possible even if the 
proposed System Property is used.

I do not know how costly it would be to implement and maintain the 
alternative approach you suggest with the negotiation required to support full 
backward compatibility. I would leave that to a different RFC. The good thing 
is that the current RFC could serve as a first step to implement the second, if 
it is agreed that this second feature is worth of being put in Geode.

Best regards,

Alberto

From: Dan Smith mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to 
connect to older Geode servers

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 will be no way 
for the client to use new features with a newer server since the version number 
of the client is set with a system property.

An alternative would be to have the client and the server need a way to 
negotiate which protocol they are going to communicate over. We do this 

Re: [Proposal] Geode Native Library Versioning

[Mario Salazar de Torres]

Thanks for pointing out this issue. A few pointers on your proposal:

  *   On my opinion the hybrid approach is the most practical one. For our 
case, we compile from the source each release, but it might seem reasonable 
that patch releases maintain both ABI and API compatibility.
  *   To make sure API and ABI compatibility it would be good to write down the 
compatibility rules in the documentation (i.e: CONTRIBUTING.md)
  *   Regarding future changes, I agree that there are lots of virtual methods 
that might not need to be virtual and might be good to re-think the public API 
for the next major release to improve it.
  *   Also, a note on the fact that we are exporting more symbols than needed. 
For most cases that's done this way to be able to test some features.
So, I'd say both things are closely related and to reduce the exported symbols, 
as well as the number of virtual methods we might need to work on the testing 
approach.

BR/
Mario.

From: Jacob Barrett 
Sent: Monday, February 1, 2021 4:34 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Geode Native Library Versioning


On Jan 29, 2021, at 3:47 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:
 I do think at least implementing some automated checking for whatever 
compatibility we intend to provide is a good idea.

I have a branch with a test using Abigail [1]. This branch depends on merging 
of a CI branch. It was actually through this branch that it was clear we have 
not been good about preserving any ABI compatibility between releases. I also 
found that we are exporting more symbols than we should in our library. All 
these need to be addressed over time. Baby steps I supposed…

[1] https://sourceware.org/libabigail/

-Jake