geode client server version not supported - Peer or client version with ordinal 100 not supported

I've a springboot app hosted on PCF trying to connect to PCC(pivotal cloud cache). I've spinned up a PCC instance and binded it to my app and pushed the app to cloud foundry. I've added all the required gemfire starter dependencies to springboot and it appears like it was able to read the locator and server information from VCAP_SERVICES. But, I see the following error on spring boot app startup.

org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120) - Could not create a new connection to server: XXX.XXX.XX.XXX(cacheserver-c3a291d1-9664-40d5-b20c-ad8dca8cd19e:1)<v3>:56152(version:GEODE 1.7.0) refused connection: 
Peer or client version with ordinal 100 not supported. Highest known version is 1.7.0 Client: /XXX.XXX.XX.XXX:39192.

at org.apache.geode.internal.cache.tier.sockets.Handshake.readMessage(Handshake.java:330) ~[geode-core-1.9.2.jar!/:?]

I'm not sure what ordinals means here and also what dependencies need to be updated.

Here are my maven dependencies..

		<dependency>
			<groupId>org.springframework.data</groupId>
			<artifactId>spring-data-gemfire</artifactId>
			<version>2.2.1.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.geode</groupId>
			<artifactId>spring-geode</artifactId>
			<version>1.2.6.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>io.pivotal.gemfire</groupId>
			<artifactId>geode-core</artifactId>
			<version>9.8.4</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.data</groupId>
			<artifactId>spring-data-geode</artifactId>
			<version>2.2.6.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.geode</groupId>
			<artifactId>spring-geode-starter</artifactId>
			<version>1.2.6.RELEASE</version>
		</dependency>

This is my config file..

@Configuration
@ClientCacheApplication(name = "Test", logLevel = "info")
@EnableCachingDefinedRegions(
    clientRegionShortcut = ClientRegionShortcut.PROXY,
    serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU)
@EnableClusterAware
@EnablePdx
public class CloudConfiguration {}

Any help?

Though you solved your issue yourself and sort of got to the gist of the problem, I wanted to provide a bit more detail here (for interested readers), as well as provide some guidance.

Let's start from the beginning:

First, your application dependencies, as shown in the Maven POM above, are very confused!

You are declaring direct, "versioned" dependencies on Spring Data GemFire (i.e. org.springframework.data:spring-data-gemfire:2.2.1.RELEASE) along with Spring Data Geode (i.e. org.springframework.data:spring-data-geode:2.2.6.RELEASE, which do not match; SD GemFire 2.2.1 != SD Geode 2.2.6) along with Spring Boot for Apache Geode & Pivotal GemFire (SBDG) (org.springframework.geode:spring-geode-starter:1.2.6.RELEASE), and then unnecessarily pull in SBDG's spring-geode (core) module, which would be transitively pulled in by the spring-geode-starter anyway, as well as declaring the org.apache.geode:geode-core module, phew!

The only dependency you need to declare in this case is 1 of SBDG's starters, either org.springframework.geode:spring-geode-starter when using Apache Geode or org.springframework.geode:spring-gemfire-starter when using Pivotal GemFire, or alternatively when deploying your Spring Boot application to PCF using PCC (in which case, the spring-gemfire-starter dependency is recommended, though not absolutely necessary since it is possible to mix GemFire/Geode peers and have Geode clients talk to GemFire serves or vice versa).

The starter pulls in Spring Data Geode (or Spring Data GemFire, depending on the starter) which pulls in the Geode (or GemFire) bits for you. That is the point of Maven/Gradle dependency management in the first place and it is better to minimize your application dependency declarations as much as possible and just let the framework/starter decide the versions of the transitive dependencies for you, especially if you don't care.

The Spring Boot project in general goes to great lengths to curate and harmonize all the dependency versions (both Spring and 3rd party libs/transitive dependencies included) for you. You only need to choose the version of the Spring Boot based on the versions of the application dependencies (e.g. Apache Geode or Pivotal GemFire) that you require.

We try to summarize those for you here:

https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix

Specifically, see:

https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix#version-compatibility-matrix

To be very transparent, this version compatibility matrix/table, roughly translates into:

1. As a developer, I am using or choosing to use SBDG 1.2.6.RELEASE.
2. SBDG 1.2.6.RELEASE is based on Spring Boot 2.2.6.RELEASE.
3. Spring Boot 2.2.6.RELEASE pulls in Spring Data Moore-SR6.
4. Spring Data Moore-SR6 (this) includes Spring Data GemFire/Geode 2.2.6.RELEASE.
5. Spring Data Geode (SDG) Moore-SR6/2.2.6.RELEASE is based on Apache Geode 1.9.x.
6. Spring Data GemFire (SDG) Moore-SR6/2.2.6.RELEASE is based on Pivotal GemFire 9.8.x.
7. Spring Data Geode includes the required (by SDG) and correct Apache Geode bits (dependencies).
8. Spring Data GemFire includes the required (by SDG) and correct Pivotal GemFire bits (dependencies).

Therefore it becomes a matter of what version of SBDG (i.e. which spring-[geode|gemfire]-starter version) do you need to use with PCC in PCF?

For that, you must have a general understanding that GemFire/Geode clients can only connect to and communicate with GemFire/Geode servers at the same version as the client or later. A newer client CANNOT talk to an older GemFire/Geode server. This is not a Spring restriction, but a GemFire/Geode restriction itself. There are many factors to why this is the case and I won't explain that here (but it roughly boils down to protocols, distributed algorithms and the rest).

By way of example, you can connect a GemFire 9.8 client to a GemFire 9.8.x server and all will be fine. That same GemFire 9.8 client can also connect to and talk with GeFire 9.9.x and 9.10.x servers. However, a GemFire 9.8 client cannot connect to or talk with a GemFire 9.7, 9.6, 9.5 or earlier server. Patch, or maintenance versions do not matter AFAIR, meaning a GemFire 9.8.7 client should be able to connect and talk to a GemFire 9.8.4 server, for example, so long as the major.minor versions match.

So now, it essentially boils down to, which version of Pivotal GemFire is the version of PCC in PCF that you are deploying your Spring Boot (Data Geode) application to, based on?

For that you need to look in the PCF/PCC documentation.

For example, PCC for PCF (now known as VMware Tanzue GemFire for VMs) version 1.11 is based on Pivotal GemFire 9.9.1. See here.

This means you could use SBDG 1.2.6.RELEASE, which is based on Spring Boot 2.2.6.RELEASE, which pulls in Spring Data Moore-SR6, which includes SDG 2.2.6.RELEASE, which is based on Apache Geode 1.9.2/Pivotal GemFire 9.8.7. This combination is fine because the older client (i.e. GemFire 9.8.7) can connect to and talk with GemFire 9.9.1, which is the baseline for PCC/VMware Tanzu GemFire for VMS 1.11.

Make sense?

If we look at PCC 1.10, again that is based on Pivotal GemFire 9.9.1.

If we look at PCC 1.9, it is based on Pivotal GemFire 9.8.6. Again, we are ok here.

If we go back to PCC 1.7, we see that PCC 1.7 was based on Pivotal GemFire 9.7.2.

Now, SBDG 1.2.6.RELEASE will NOT work with PCC 1.7 since SBDG 1.2.6.RELEASE is based on GemFire 9.8 (newer) and PCC 1.7 is based on GemFire 9.7 (older). A 9.8 client cannot connect to and talk with a 9.7 server, therefore, we must go back a SBDG major.minor version to SBDG 1.1.x, where SBDG 1.1.x is based on Spring Boot 2.1, which pulls in Spring Data Lovelace/2.1, which includes SDG 2.1.x, which is based on Apache Geode 1.6 and Pivotal GemFire 9.5, respectively.

NOTE: While SDG is "compatible" with newer, none "baseline" versions of GemFire/Geode, we do not "support" the combination. For example, SDG Lovelace/2.1 is "based on" GemFire 9.5/Geode 1.6 only, but is "compatible with" GemFire 9.6/9.7 and Geode 1.7/1.8. If you move beyond GemFire 9.7 to, e.g. 9.8 and Geode 1.8 to 1.9, then of course, you should move to SDG Moore/2.2, since it is "based on" GemFire 9.8/Geode 1.9. Compatibility != Support.
Anyway, this is to say, you can upgrade your client driver version (i.e. GemFire/Geode client version, if necessary). See here for more details. This Wiki page is a WIP.

The Cloud Cache Developer Website also contains details to help get you started.

Finally, I also built this Getting Started Sample (with Guide and Source Code) in the SBDG project itself, that gets you up and running quickly by starting at start.spring.io.

Now, regarding your configuration...

@Configuration
@ClientCacheApplication(name = "Test", logLevel = "info")
@EnableCachingDefinedRegions(
    clientRegionShortcut = ClientRegionShortcut.PROXY,
    serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU)
@EnableClusterAware
@EnablePdx
public class CloudConfiguration {}

This can be simplified to:

@Configuration
@EnableCachingDefinedRegions(
  serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU
)
@EnableClusterAware
public class CloudConfiguration {}

SBDG "auto-configures" a ClientCache instance for you, by default. See here.

In fact, you should be careful when declaring annotations, explicitly, since then you are overriding the auto-configuration (i.e. you are overriding the "convention" by applying explicit "configuration", which tells Boot that you know what you are doing; Make sure that is actually the case!) See here and here and here and here and here.

Many of the annotation attributes (e.g. ClientCacheApplication.name or ClientCacheApplication.logLevel) can be expressed as SDG properties in a Spring Boot applications.properties file, making the configuration more "configurable".

For example:

# Spring Boot application.properties.
spring.data.gemfire.name=Test
spring.data.gmefire.cache.log-level=INFO

See here and here for more details.

You also do not need to enable PDX explicitly since again SBDG auto-configures PDX for you. See here.

The default ClientRegionShortcut is PROXY, though I don't mind being "explicit" about it either. You simply just have to be careful in a Spring Boot context with auto-configuration since you might "override" the auto-config and put the responsibility of managing the configuration correctly on yourself. So declare configuration with intent, not blindly.

Hope this helps!

Solution: I downgraded the SpringBoot client version to v1.7 and it worked fine. Although, I see authentication issue now.