Compatibility question

[georgeharley]

Hi,

Are more recent versions of SBDG developed to work with Spring Boot 2.5.x and 2.6.x compatible with VMWare Tanzu GemFire versions 9.10.x? The compatibility information on the SBDG wiki states NA for this combination but I am not entirely sure if that means no compatibility or that it has not been tested.

[jxblum]

Effectively, from a technical point of view, it means no compatibility.

SBDG directly depends on Spring Data for Apache Geode (SDG). The SBDG spring-geode module is essentially the core module for all other SBDG modules in the project (e.g. like the spring-geode-starter; see here, which is used by the Spring Initializer at start.spring.io).

What does this mean exactly?

Well, each generation / version of SBDG will invariably depend increasingly on newer versions of Spring Data, which in large part is actually guided by Spring Boot.

Spring Boot is pulling in updated or newer versions of Spring Data (along with other Spring and 3rd party dependencies) with each generation (major version) as well as minor versions (major.minor).

For example, Spring Boot 2.6.x pulls in Spring Data BOM 2021.1.0 (currently; generally 2021.1.x). The Spring Data BOM 2021.1.0 pulls in Spring Data for Apache Geode (SDG) 2.6.0. SDG 2.6.0 in turn pulls in, or rather, is based on Apache Geode 1.14.0.

By comparison, Spring Boot 2.5.x pulls in Spring Data BOM 2021.0.7 (currently; generally 2021.0.x). Spring Data BOM 2021.0.7 pulls in Spring Data for Apache Geode (SDG) 2.5.7. SDG 2.5.7 pulls in, or rather is based on Apache Geode 1.13.4.

As the Version Compatibility Matrix outlines, even SBDG 1.4.x was indirectly based on Apache Geode 1.13.x (currently 1.13.4).

You have to go all the way back to SBDG 1.3.x to find a version that is compatible with GemFire bits (i.e. 9.10.x), which by the Spring Boot support policy is already OSS EOL, as of May 2021.

NOTE: Spring Boot 2.3.x commercial support extends until August 2022.

The reason is due to the relationship between Apache Geode and VMware Tanzu GemFire itself, and nothing to do with Spring in general, or all things Spring for Apache Geode bits in particular.

VMware (Pivotal) stopped releasing standalone GemFire bits after 9.10. Currently, GemFire 9.10.11 is the latest release available from the VMware Tanzu Network.

Unfortunately, GemFire 9.10.x was last based on Apache Geode 1.12.x. This means there is no "compatible" version of GemFire based on Apache Geode after 1.12.x, such as GemFire for Apache Geode 1.13.x and GemFire for Apache Geode 1.14.x.

This is significant mainly since newer GemFire/Geode clients CANNOT communicate with older GemFire servers. This is a GemFire/Geode limitation, nothing to do with Spring.

There is also the possibility that certain Apache Geode functions or behavior on which SDG would be based using a newer version of Apache Geode would not be available in the older GemFire versions.

Therefore, it not 100% reliable to say that the Spring bits for Apache Geode at newer versions will be compatible and still work unhindered with older GemFire versions. We cannot make that claim and we certainly will not support the combination if something does not work, primarily because it is out of our control.

Having said this... users have successfully downgraded newer versions of SBDG (e.g. 1.5) based on newer versions of Apache Geode (1.13) and used SBDG (e.g. 1.5.x) with Apache Geode 1.12 (or even earlier bits, 1.11/1.10). This mainly occurs because users were running older GemFire servers (clusters).

This is especially true for users of VMware Tanzu GemFire for VMs (i.e. the old Pivotal Cloud Cache (PCC) on Pivotal CloudFoundry (PCF), now known as the VMware Tanzu Application Service for VMs). However, even VMware Tanzu GemFire for VMs is being rebased on Apache Geode, as you can see in the 1-14 docs (See "Software component version").

Anyway, while users have successfully done this, the mileage varies of course, and this is still not supported. Only product version combinations specifically listed in the Version Compatibility Matrix are specifically tested, approved and supported. Users who venture outside the compatible versions defined in the matrix do so at their own risk.

Good question, but I hope this clarifies the matter.

[georgeharley]

@jxblum Sincere thanks for the detailed response, it is very useful. We are going to take the matter up with our support team to decide on the best course of action.

[jxblum]

This question was just asked (again) on StackOverflow, here.

BACKGROUND:

To make this absolutely clear and to summarize.

1) The SBDG Version Compatibility Matrix, and specifically the (non-EOL) "Supported Versions" is the definitive word on version compatibility and support.

2) The current and latest version of VMware Tanzu (Pivotal) GemFire, 9.10.x was last based on Apache Geode 1.12. This pairing is outside of the Spring team's control. You can verify this in the following page and the table listing all versions. You won't see versions of GemFire for Apache Geode versions 1.13 and later. This is also why the SBDG Version Compatibility Matrix shows the GemFire version as "NA" from Apache Geode 1.13 and after.

3) Spring Boot for Apache Geode (SBDG), and by extension, Spring Data for Apache Geode (SDG) was rebased on Apache Geode 1.13 as of SDG 2.4.x and SBDG 1.4.x (which is based on Spring Boot 2.4.x). So, because there is not "compatible" GemFire version, we cannot pair GemFire in these releases that are now based on Apache Geode 1.13 and later.

4) It is also problematic to ship GemFire bits with SDG, and by extension, SBDG, since GemFire is NOT OSS, and NOT available in Maven Central, unlike Apache Geode. Therefore, for the foreseeable future, SDG and SBDG (along with all Spring for Apache Geode bits, include SSDG and STDG) will be exclusively base on OSS, Apache Geode bits going forward.

PROBLEM:

Technically, this is very much a GemFire/Geode problem and less to do with Spring, in general.

1) The GemFire/Geode teams should produce bits of GemFire based on all major.minor version of Apache Geode to maintain compatibility.

2) Alternatively, they could (and probably should) make newer client drivers able to communicate with older GemFire/Geode servers, even if at a limited capability.

SOLUTION:

As an experiment, I tried to downgrade the latest SBDG bits (as of this writing, that is 1.6.1) to Apache Geode 1.12.6. SBDG would not even compile much less run. So...

1) I think downgrading is risky (for example)! It highly depends on the functions of Apache Geode used and required by your Spring Boot application use case. Proceed at your own risk.

2) I think it would potentially be better to upgrade SBDG 1.3.x, based on Apache Geode 1.12, and by extension, GemFire 9.10, here, to Spring Boot 2.6.1 (currently). You can bump the patch versions of GemFire/Geode to the latest if necessary (e.g. Apache Geode 1.12.6 (and GemFire 9.10.12), which addresses the current Log4j vulnerability).

So that is:

• SBDG 1.3.12.RELEASE
• Spring Boot 2.6.1
• Apache Geode 1.12.6 / VMware Tanzu GemFire 9.10.12.

See here.

Even this upgrade was not trivial and risky!

For example, it required a downgrade of Jackson JSON support in Spring Boot, where Boot 2.6.1 is based on Jackson 2.13.0, but Boot 2.3.x is based on Jackson 2.11.4.

So, there are risks either way you must weigh them accordingly.

Regards John