Integrating Geode with the Rapid membership service
There was an effort to modularize the membership system in Geode and I spent some time seeing if a different membership service could be integrated with Geode in place of the current implementation. I wrote a blog post about it here: https://brucesch.blogspot.com/2021/01/integrating-apache-geode-with-rapid.html
Inputs for efficient querying
Hello Team,
I am loading data into Geode (V 1.12) with the following *Key (of type
String)* and *value (custom java object - ValueObject)*.
*public class ValueObject implements Serializable {*
* private int id;*
* private String keyColumn; <- Region.Key *
* private String column_2; <-- Json document*
* private String column_3;*
* private String column_4*
* //few more string type members*
*}*
*Keycolum* is a normal string of around 8 chars, like "12345678",
"23456789" etc...
*In ValueObject, column_2 is of type string and having a values of type
valid JSON doc as bellow; *
{"k1" : "v1", "k3" : "v3", "k6" : "v6", "k7" : "v7", *"k10" : "v7"*, "k12"
: "v12", "k13" : "v13"}
{"k2" : "v2", "k3" : "v3", "k4" : "v4", "k6" : "v6", *"k10" : "v10"*, "k13"
: "v13", "k14" : "v14"}
{"k1" : "v1", "k2" : "v2", "k6" : "v6", "k8" : "v8", "k10" : "v7", "k12" :
"v12", "k13" : "v13", "k14" : "v14"}
.
after storing the data in Geode i need to run following two queries.
*Query to be supported.*
*Q1. //query with filter on keyColumn*
"select d.keyColumn, d.column_2, d.column_3, d.column_4
from /DATA_REGION.keyset key
where (key IN SET('12345678', '23456789', '34567890'))"
*Q2. //query with filter on column_2 attribute, something like "where
d.column_2.k10 IN SET('v10', 'v15', 'v7'); *
"select d.keyColumn, d.column_2, d.column_3, d.column_4
from /DATA_REGION v
where v.column_2.k10 INSET('v10', 'v15', 'v7')"
I am able to run the Q1 but not sure *how to achieve Q2 (form a OQL for
this case)*...?
Request team to help, how can i efficiently form and execute above kind of
queries with geode OQL...?
Also advise, what kind of index are recommended to get higher query
performance for above queries...?
Thanks
Ankit.
Re: Inputs for efficient querying
For the best performance, you should store column2 as a java Map instead of a
String which contains a json document. If column2 was Map, you
could do a query like this:
SELECT * FROM /exampleRegion r WHERE r.column2['k1'] IN SET('v10', 'v15', 'v7')"
You can create an index on the map to optimize this sort of query
gfsh>create index --name="IndexName" --expression="r.column2[*]"
--region="/exampleRegion r"
This page might be helpful
https://geode.apache.org/docs/guide/112/developing/query_index/creating_map_indexes.html
In addition, I noticed that your value implements Serializable. You will get
better performance out of the query engine if you configure PDX serialization
for your object, either by configuring the auto serializer or implementing
PdxSerializable. That avoids the need to deserialize your entire value on the
server to query/index it.
-Dan
From: ankit Soni
Sent: Friday, January 29, 2021 9:32 AM
To: dev@geode.apache.org
Subject: Inputs for efficient querying
Hello Team,
I am loading data into Geode (V 1.12) with the following *Key (of type
String)* and *value (custom java object - ValueObject)*.
*public class ValueObject implements Serializable {*
* private int id;*
* private String keyColumn; <- Region.Key *
* private String column_2; <-- Json document*
* private String column_3;*
* private String column_4*
* //few more string type members*
*}*
*Keycolum* is a normal string of around 8 chars, like "12345678",
"23456789" etc...
*In ValueObject, column_2 is of type string and having a values of type
valid JSON doc as bellow; *
{"k1" : "v1", "k3" : "v3", "k6" : "v6", "k7" : "v7", *"k10" : "v7"*, "k12"
: "v12", "k13" : "v13"}
{"k2" : "v2", "k3" : "v3", "k4" : "v4", "k6" : "v6", *"k10" : "v10"*, "k13"
: "v13", "k14" : "v14"}
{"k1" : "v1", "k2" : "v2", "k6" : "v6", "k8" : "v8", "k10" : "v7", "k12" :
"v12", "k13" : "v13", "k14" : "v14"}
.
after storing the data in Geode i need to run following two queries.
*Query to be supported.*
*Q1. //query with filter on keyColumn*
"select d.keyColumn, d.column_2, d.column_3, d.column_4
from /DATA_REGION.keyset key
where (key IN SET('12345678', '23456789', '34567890'))"
*Q2. //query with filter on column_2 attribute, something like "where
d.column_2.k10 IN SET('v10', 'v15', 'v7'); *
"select d.keyColumn, d.column_2, d.column_3, d.column_4
from /DATA_REGION v
where v.column_2.k10 INSET('v10', 'v15', 'v7')"
I am able to run the Q1 but not sure *how to achieve Q2 (form a OQL for
this case)*...?
Request team to help, how can i efficiently form and execute above kind of
queries with geode OQL...?
Also advise, what kind of index are recommended to get higher query
performance for above queries...?
Thanks
Ankit.
Canceled: apache/geode-native#2973 (develop - 78d2fbf)
Build Update for apache/geode-native - Build: #2973 Status: Canceled Duration: ? Commit: 78d2fbf (develop) Author: Blake Bender Message: GEODE-8887: Refactor EventIdTSS class (#733) - Use Meyers singleton pattern for global singleton (threadId), and thread local singleton EventIdTSS - rename all member variables in EventId and EventIdTSS classes - clean up logic slightly around global threadId atomic var - rename EventId getter methods for clarity View the changeset: https://github.com/apache/geode-native/compare/a4afaf31d973...78d2fbf67e81 View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/215284113?utm_medium=notification&utm_source=email Restart your build: https://travis-ci.com/github/apache/geode-native/builds/215284113?utm_medium=notification&utm_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&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Canceled: apache/geode-native#2974 (develop - 6391584)
Build Update for apache/geode-native - Build: #2974 Status: Canceled Duration: ? Commit: 6391584 (develop) Author: Blake Bender Message: GEODE-8871: parse server response messages for PUT and CONTAINS_KEY (#730) - parse server response messages for PUT and CONTAINS_KEY - Fix bad regex (copy/paste error) - Also some formatting fixes View the changeset: https://github.com/apache/geode-native/compare/78d2fbf67e81...6391584c195a View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/215285235?utm_medium=notification&utm_source=email Restart your build: https://travis-ci.com/github/apache/geode-native/builds/215285235?utm_medium=notification&utm_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&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Canceled: apache/geode-native#2975 (develop - c655c68)
Build Update for apache/geode-native - Build: #2975 Status: Canceled Duration: ? Commit: c655c68 (develop) Author: M. Oleske Message: Update to ace 7 (#732) Authored-by: M. Oleske View the changeset: https://github.com/apache/geode-native/compare/6391584c195a...c655c6853613 View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/215285531?utm_medium=notification&utm_source=email Restart your build: https://travis-ci.com/github/apache/geode-native/builds/215285531?utm_medium=notification&utm_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&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
[Proposal] Geode Native Library Versioning
I would appreciate some feedback on this proposal by the end of day Friday, February 5th, 2021. TLDR; The proposal is to formalize what has been effectively the status quo for Geode Native release in the current source form and any future binary form. The Problem Geode Native, specifically the C++ client, has a versioning problem. This is not a problem with compatibility or versioning between the Geode Native libraries and the Geode Server but rather an issue of compatibility between consumer applications and the Geode Native Libraries. Geode subscribes to the semantic version doctrine [1]. Semver describes API compatibility requirements but is largely silent on ABI, though it can be extended to the ABI. API and ABI compatibility are not the same thing. You can have an API compatible change that breaks the ABI and an ABI compatible change that breaks API. The intersection of the two creates even more complex rules around maintaining compatibility between release. All this in combination makes for really restrictive rules when trying to release even the smallest updates to a library. For source releases this is really easy, you build what you need with your application and all should be happy. For binary releases this becomes a little harder. Since the consumer isn’t in control of what is built or how it is built, binary incompatibilities between releases can creep in. The difference is in the API vs ABI compatibility and while more pronounced in some languages it can exist in all. For example, one could create an ABI incompatibility in Java by compiling class files with a newer version of the runtime than the previous release. Those new classes, while API compatible, would not be loadable by the older runtime and classes thus making them ABI incompatible. In C++ not only does the runtime version play a role but the physical layout in memory, name mangle strategies, optimizations and other things can cause ABI incompatibility [2]. Geode Native has not maintained ABI compatibility between minor releases. Minor releases have included changes to exported types and methods changing. In the upcoming release of 1.14 there are a few incompatible changes around a new virtual method added to a base type. While the C++ language does not define how compilers and linkers should treat such changes they almost universally result in layout changes of the vtable and thus ABI incompatibilities. The results of these incompatibilities at the ABI level are undefined and hard to diagnose. In a pinch if a consumer placed a patched library into their application that had an ABI compatibility issue it may appear to work but over time could exhibit odd behavior. Best case scenario it causes the application to exit but worst case it silently executes the wrong virtual methods resulting in the loss of data. ABI Versioning Options We must communicate ABI versioning to consumers of the library. Before we can do that we must decide on ABI versioning rules. Semantic Versioning for ABI This is probably the most restrictive of our options. If the ABI is included in semantic versioning then no changes can be made to types with virtual methods. For example, the recent change to add expected domain names to PDX types would not have been possible until a major release. This change resulted in the change to a base type virtual method, thus a vtable change and an ABI incompatible change. The benefit to consumers is that they never need to recompile their applications for minor or patch updates unless taking advantage of non-breaking API compatible changes. No ABI Versioning If ABI is not considered as part of the semantic versioning scheme then every release expects a complete recompile from all applications. This is an easy rule for consumers to follow but isn’t ideal for minor patches where it is likely a drop in binary could be possible and certainly less disruptive than a full recompile. Hybrid Semantic Versioning We could communicate some custom rule where only patch level semantic versioned releases are ABI compatible and any major or minor release requires a recompile. I believe we are effectively operating in this space but without explicit intent, though no care is being taken to verify that even patch releases have been ABI compatible. Proposal I propose that we adopt a hybrid semantic versioning convention that establishes intent to maintain ABI compatibility only between patch releases. Major releases will contain both API and ABI incompatible changes. The library may not be replaced without code changes and recompilation. Changes to API and ABI will be documented in a change log for easy reference. Minor releases may contain API compatible changes and should be assumed to have ABI incompatible changes. The library may not be replaced without recompilation but code changes are not necessary. Changes to API and ABI will be documented in a change log for easy reference. Patch r
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 Sent: Friday, January 29, 2021 1:56 AM To: 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 already for WAN. WAN senders can be a higher version than receivers, otherwise we couldn't upgrade an Active/Active WAN. What happens is that the WAN receiver will accept a newer versioned client, and it sends back its own version. The client reads the receivers version and adjusts accordingly. You can see this in ClientSideHandshakeImpl.handshakeWithServer. This will require a lot of testing to make sure that users won't see strange corruption related errors related to serialization changes. -Dan From: Alberto Gomez Sent: Tuesday, January 26, 2021 6:45 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers 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 to allow newer Geode clients to connect to older Geode servers 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 current version in the handshake) is kept when the flag is not used. On the other hand if in the future we have clients that are partially compatible with an older server version, the System Property with the version could allow these clients to connect to that server version assuming that they will not use any incompatible feature. Alberto From: Patrick Johnson Sent: Friday, January 22, 2021 8:35 PM To: dev@geode.apache.org Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers 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 any versions that it is known to be compatible with? Then you wouldn’t even have to set the property. > On Jan 22, 2021, at 11:05 AM, Alberto Gomez wrote: > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2Boption%2Bto%2Ballow%2Bnewer%2BGeode%2Bclients%2Bto%2Bconnect%2Bto%2Bolder%2BGeode%2Bservers&data=04%7C01%7Cdasmith%40vmware.com%7C776eddfeec43423ccfee08d8c2091d4d%
Re: [Proposal] Geode Native Library Versioning
** sorry for the trashed formatting originally ** I would appreciate some feedback on this proposal by the end of day Friday, February 5th, 2021. TLDR; The proposal is to formalize what has been effectively the status quo for Geode Native release in the current source form and any future binary form. = The Problem = Geode Native, specifically the C++ client, has a versioning problem. This is not a problem with compatibility or versioning between the Geode Native libraries and the Geode Server but rather an issue of compatibility between consumer applications and the Geode Native Libraries. Geode subscribes to the semantic version doctrine [1]. Semver describes API compatibility requirements but is largely silent on ABI, though it can be extended to the ABI. API and ABI compatibility are not the same thing. You can have an API compatible change that breaks the ABI and an ABI compatible change that breaks API. The intersection of the two creates even more complex rules around maintaining compatibility between release. All this in combination makes for really restrictive rules when trying to release even the smallest updates to a library. For source releases this is really easy, you build what you need with your application and all should be happy. For binary releases this becomes a little harder. Since the consumer isn’t in control of what is built or how it is built, binary incompatibilities between releases can creep in. The difference is in the API vs ABI compatibility and while more pronounced in some languages it can exist in all. For example, one could create an ABI incompatibility in Java by compiling class files with a newer version of the runtime than the previous release. Those new classes, while API compatible, would not be loadable by the older runtime and classes thus making them ABI incompatible. In C++ not only does the runtime version play a role but the physical layout in memory, name mangle strategies, optimizations and other things can cause ABI incompatibility [2]. Geode Native has not maintained ABI compatibility between minor releases. Minor releases have included changes to exported types and methods changing. In the upcoming release of 1.14 there are a few incompatible changes around a new virtual method added to a base type. While the C++ language does not define how compilers and linkers should treat such changes they almost universally result in layout changes of the vtable and thus ABI incompatibilities. The results of these incompatibilities at the ABI level are undefined and hard to diagnose. In a pinch if a consumer placed a patched library into their application that had an ABI compatibility issue it may appear to work but over time could exhibit odd behavior. Best case scenario it causes the application to exit but worst case it silently executes the wrong virtual methods resulting in the loss of data. = ABI Versioning Options = We must communicate ABI versioning to consumers of the library. Before we can do that we must decide on ABI versioning rules. == Semantic Versioning for ABI == This is probably the most restrictive of our options. If the ABI is included in semantic versioning then no changes can be made to types with virtual methods. For example, the recent change to add expected domain names to PDX types would not have been possible until a major release. This change resulted in the change to a base type virtual method, thus a vtable change and an ABI incompatible change. The benefit to consumers is that they never need to recompile their applications for minor or patch updates unless taking advantage of non-breaking API compatible changes. == No ABI Versioning == If ABI is not considered as part of the semantic versioning scheme then every release expects a complete recompile from all applications. This is an easy rule for consumers to follow but isn’t ideal for minor patches where it is likely a drop in binary could be possible and certainly less disruptive than a full recompile. == Hybrid Semantic Versioning == We could communicate some custom rule where only patch level semantic versioned releases are ABI compatible and any major or minor release requires a recompile. I believe we are effectively operating in this space but without explicit intent, though no care is being taken to verify that even patch releases have been ABI compatible. = Proposal = I propose that we adopt a hybrid semantic versioning convention that establishes intent to maintain ABI compatibility only between patch releases. Major releases will contain both API and ABI incompatible changes. The library may not be replaced without code changes and recompilation. Changes to API and ABI will be documented in a change log for easy reference. Minor releases may contain API compatible changes and should be assumed to have ABI incompatible changes. The library may not be replaced without recompilation but code changes are not nece
Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers
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 Sent: Friday, January 29, 2021 11:40 AM To: 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 Sent: Friday, January 29, 2021 1:56 AM To: 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 already for WAN. WAN senders can be a higher version than receivers, otherwise we couldn't upgrade an Active/Active WAN. What happens is that the WAN receiver will accept a newer versioned client, and it sends back its own version. The client reads the receivers version and adjusts accordingly. You can see this in ClientSideHandshakeImpl.handshakeWithServer. This will require a lot of testing to make sure that users won't see strange corruption related errors related to serialization changes. -Dan From: Alberto Gomez Sent: Tuesday, January 26, 2021 6:45 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers 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 to allow newer Geode clients to connect to older Geode servers 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 current version in the handshake) is kept when the flag is not used. On the other hand if in the future we have clients that are partially compatible with an older server version, the System Property with the version could allow these clients to connect to that server version assuming that they will not use any incompatible feature. Alberto From: Patrick Johnson Sent: Friday, Janua
Re: [Proposal] Geode Native Library Versioning
ABI compatibility with the java layer has come up before [1]. At the time we decided to keep binary compatibility for the Java code. That said, it's not common to break binary without breaking source compatibility in Java. C++ is a different animal, so I can see wanting to do something different there. I do think at least implementing some automated checking for whatever compatibility we intend to provide is a good idea. [1] https://lists.apache.org/x/thread.html/ebdeabc24ce0ff418427021dfbbd45aceb51939f25de4aba7bb5c97b@%3Cdev.geode.apache.org%3E From: Jacob Barrett Sent: Friday, January 29, 2021 12:00 PM To: dev@geode.apache.org Subject: Re: [Proposal] Geode Native Library Versioning ** sorry for the trashed formatting originally ** I would appreciate some feedback on this proposal by the end of day Friday, February 5th, 2021. TLDR; The proposal is to formalize what has been effectively the status quo for Geode Native release in the current source form and any future binary form. = The Problem = Geode Native, specifically the C++ client, has a versioning problem. This is not a problem with compatibility or versioning between the Geode Native libraries and the Geode Server but rather an issue of compatibility between consumer applications and the Geode Native Libraries. Geode subscribes to the semantic version doctrine [1]. Semver describes API compatibility requirements but is largely silent on ABI, though it can be extended to the ABI. API and ABI compatibility are not the same thing. You can have an API compatible change that breaks the ABI and an ABI compatible change that breaks API. The intersection of the two creates even more complex rules around maintaining compatibility between release. All this in combination makes for really restrictive rules when trying to release even the smallest updates to a library. For source releases this is really easy, you build what you need with your application and all should be happy. For binary releases this becomes a little harder. Since the consumer isn’t in control of what is built or how it is built, binary incompatibilities between releases can creep in. The difference is in the API vs ABI compatibility and while more pronounced in some languages it can exist in all. For example, one could create an ABI incompatibility in Java by compiling class files with a newer version of the runtime than the previous release. Those new classes, while API compatible, would not be loadable by the older runtime and classes thus making them ABI incompatible. In C++ not only does the runtime version play a role but the physical layout in memory, name mangle strategies, optimizations and other things can cause ABI incompatibility [2]. Geode Native has not maintained ABI compatibility between minor releases. Minor releases have included changes to exported types and methods changing. In the upcoming release of 1.14 there are a few incompatible changes around a new virtual method added to a base type. While the C++ language does not define how compilers and linkers should treat such changes they almost universally result in layout changes of the vtable and thus ABI incompatibilities. The results of these incompatibilities at the ABI level are undefined and hard to diagnose. In a pinch if a consumer placed a patched library into their application that had an ABI compatibility issue it may appear to work but over time could exhibit odd behavior. Best case scenario it causes the application to exit but worst case it silently executes the wrong virtual methods resulting in the loss of data. = ABI Versioning Options = We must communicate ABI versioning to consumers of the library. Before we can do that we must decide on ABI versioning rules. == Semantic Versioning for ABI == This is probably the most restrictive of our options. If the ABI is included in semantic versioning then no changes can be made to types with virtual methods. For example, the recent change to add expected domain names to PDX types would not have been possible until a major release. This change resulted in the change to a base type virtual method, thus a vtable change and an ABI incompatible change. The benefit to consumers is that they never need to recompile their applications for minor or patch updates unless taking advantage of non-breaking API compatible changes. == No ABI Versioning == If ABI is not considered as part of the semantic versioning scheme then every release expects a complete recompile from all applications. This is an easy rule for consumers to follow but isn’t ideal for minor patches where it is likely a drop in binary could be possible and certainly less disruptive than a full recompile. == Hybrid Semantic Versioning == We could communicate some custom rule where only patch level semantic versioned releases are ABI compatible and any major or minor release requires a recompile. I believe we ar
Canceled: apache/geode-native#2976 (develop - 3450bac)
Build Update for apache/geode-native - Build: #2976 Status: Canceled Duration: ? Commit: 3450bac (develop) Author: Michael Martell Message: GEODE-8836: Fix incorrect schema location for cli tests (#721) View the changeset: https://github.com/apache/geode-native/compare/c655c6853613...3450baca23d0 View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/215285728?utm_medium=notification&utm_source=email Restart your build: https://travis-ci.com/github/apache/geode-native/builds/215285728?utm_medium=notification&utm_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&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
