Upgrading Tanzu GemFire 9.15 and 10.0 to 10.2 or 10.3: Upgrade Path, Java 17, Jakarta and Rolling Upgrades

The short answer

Broadcom's product lifecycle table ended general support for Tanzu GemFire 9.15 on 31 October 2025 and for 10.0 on 30 April 2026. The last patches were 9.15.16, on 8 July 2025, and 10.0.8, on 17 March 2026. The GemFire 9.15 and GemFire 10.0 end-of-life pages have the details.

The targets with time left are 10.2, supported until 31 October 2028, and 10.3, supported until 31 July 2029. 10.1 ends on 28 February 2027, so it is a stepping stone, not a destination.

• From 10.0, the 10.2 and 10.3 release notes allow a direct upgrade.
• From 9.15, a direct upgrade is not possible. The release notes give the path as 9.x to 10.1, then to 10.2 or 10.3, and the 10.1 notes say a cluster on 9.15.13 or later can only move to 10.1.2 or later.
• To 10.3, every member, client and application has to run on JDK 17 or later, and 10.3 has moved from javax.* to jakarta.* along with major upgrades to the libraries it bundles.

Support dates and current releases

Dates come from Broadcom's product lifecycle table for VMware Tanzu GemFire and the release notes on Broadcom TechDocs. Every line is on the GemFire and Geode end-of-life tracker.

The upgrade path

The reason for the two steps is in the 10.2 upgrade guide. GemFire 10.2 removed the JGroups library that provided UDP-based communication, and releases before 10.0 need UDP, so a 9.x member and a 10.2 member cannot talk. The guide also says to check two properties before going to 10.2: disable-tcp and use-udp-membership-messenger must be unset or false.

The 10.2 upgrade guide words the first hop as 10.0 or 10.1, while the 10.2 and 10.3 release notes say 10.1. For a 9.15 cluster this makes no difference, since 10.0 has itself left general support. Go through the latest 10.1 release.

Java requirements

No GemFire release supports virtual threads, including on JDK 21 and 25. On JDK 17 and later, GemFire needs reflective access to JDK types used in your data, and the Java support page lists the --add-opens and --add-exports options every member and client needs. gfsh adds the base set when it starts locators and servers, but client applications have to add them themselves. The product ships an argument file that opens every JDK 17 package for this purpose. gfsh also selects ZGC by default on JDK 17 and Generational ZGC on JDK 21 and 25, so expect different GC behaviour after the move.

Our recommendation: move members and clients to JDK 17 on 10.1 or 10.2 first, where JDK 8 and 11 are still supported, so the JVM change and the 10.3 library changes do not land in the same window.

What changed in GemFire 10.0 for 9.x users

• Classloader isolation. Deployed JAR files load into their own classloaders, isolated from the system and from each other. GemFire 9 used chained classloading. Functions, listeners and serializers that relied on classes from another deployed JAR need testing, or the members can be started with --disable-classloader-isolation=true while you fix them.
• Changed defaults. enable-time-statistics is now true, the client pool idle timeout default rose from 5 seconds to 2 minutes, and the cache server's default maximum connections rose from 800 to 1,200.
• Session caching. The Tomcat session module gained Tomcat 10 support, kept Tomcat 8.5 and 9, and dropped Tomcat 7, Tomcat 8 and tc Server.
• Environment. GEMFIRE_HOME replaces GEODE_HOME, which is deprecated.

Breaking changes in 10.3: Jakarta EE and the bundled libraries

GemFire 10.3 is compiled with JDK 17 and has moved from the javax.* APIs to jakarta.*. The libraries it bundles moved by a major version at the same time:

10.3 also stops bundling Spring Boot, Spring LDAP, Spring HATEOAS, SnakeYAML, several legacy Apache Commons libraries, Apache Shiro and the Swagger and springdoc libraries. Server-side code that used any of these from GemFire's classpath has to declare them itself, and code that used Jackson 2 or javax.servlet classes from the server classpath has to be updated. The other breaking changes in 10.3:

• Extensions. GemFire Search, Vector Database, Session Management and Distributed Types must be on their 2.x releases, upgraded at the same time as GemFire. The 1.x extensions do not work on 10.3.
• Security managers. A SecurityManager that uses Shiro must add Shiro as its own dependency, or members fail to start.
• SLF4J is no longer in gemfire-core. Add slf4j-api or gemfire-log4j if your code compiles against it.
• Client pool minimums. ping-interval, load-conditioning-interval, idle-timeout and socket-connect-timeout must be at least 1,000 ms and read-timeout at least 100 ms, apart from the documented special values. Lower settings throw IllegalArgumentException.
• WAN transport filters. Any gateway-transport-filter configuration makes startup fail with GemFireConfigException. Remove it, or set -Dgemfire.cache.wan.enableGatewayTransportFilter=true on every member as a temporary measure that Broadcom does not recommend for production.
• WAN conflict resolution. GatewayConflictResolver.onEvent() is now called for every WAN update to an existing entry. The release notes give a guard to restore the old behaviour.
• Statistics. Several CacheServerStats counters were replaced by a new three-counter pattern. Dashboards built on the old names need updating.
• Swagger UI is gone from the Developer REST API. The REST endpoints themselves are unchanged.

10.3 also deprecates subregions, conserve-sockets, off-heap memory, SnappyCompressor, slow-receiver asynchronous queueing and the pr-single-hop-enabled, max-connections and min-connections pool attributes. Pulse, deprecated since 10.1, is due to be removed in 10.4.

Changes in 10.1 and 10.2 to know about

• Backups during a mixed-version cluster (10.1). Once a locator runs 10.1 or later, backup disk-store refuses to run while any member is older than 10.1. Take disk store backups before the first locator moves.
• Peer connection pooling (10.2). With conserve-sockets=false, the default, peer-to-peer messaging now pools connections.
• WAN error handling (10.2). REMOVE_FROM_QUEUE_ON_EXCEPTION is deprecated in favour of the GatewayEventFailureListener interface.
• OS statistics (10.2). OS-level statistics now come from the OSHI library, replacing LinuxSystemStats and LinuxProcessStats.
• Container image (10.2.1). The GemFire image moved to RHEL UBI 10, which on Intel needs AVX2 (x86-64-v3).

Spring for GemFire

From GemFire 9.15, Broadcom's Spring Boot, Spring Data and Spring Session for VMware GemFire replaced the open source Spring projects for Apache Geode for GemFire users. The artifacts come from Broadcom's repository rather than repo.spring.io, and the artifact names carry both versions, for example spring-boot-3.1-gemfire-10.0. A client application therefore picks an artifact for a specific Spring Boot generation and a specific GemFire minor version.

Our recommendation: treat the Spring Boot version and the GemFire target as one decision. Find the Spring for GemFire artifact that matches your Spring Boot line and the GemFire release you are moving to before you schedule the server upgrade, and plan the client rebuild alongside it. Applications on Spring Boot 2.7 are on javax.* and need their own move to Spring Boot 3 or 4; our Spring Boot 2 to 3 migration guide and javax to jakarta guide cover that work.

Rolling upgrade

Broadcom's planning guide allows peers and cache servers on different minor versions of the same major version during a rolling upgrade, and recommends rolling upgrades where possible, with an offline upgrade as the fallback. The rules from the rolling upgrade procedure:

• Every partitioned region must have full redundancy before you start and before you stop each member. A cluster with non-redundant partitioned regions cannot be rolled, because entries are lost when a server leaves.
• Do not create or destroy regions, or change region attributes, while versions are mixed.
• If startup-recovery-delay is -1, rebalance after each member restarts. Otherwise wait for the automatic rebalance to finish before stopping the next server.
• Upgrade locators first, then data members, then clients.
• After all locators are upgraded, do not start any process on the old version. The guide warns it may be refused or may cause a deadlock.

The order for a 9.15 cluster:

1. Back up disk stores, deployed JARs, configuration and data. Export the cluster configuration with gfsh export cluster-configuration, or save each member's cache.xml and gemfire.properties.
2. Check redundancy on every partitioned region.
3. Roll to 10.1.2 or later: locators, then servers, then clients, installing the new version alongside the old one on each host.
4. Test classloader isolation with your deployed functions, or set --disable-classloader-isolation=true while you fix them.
5. Clear UDP settings so disable-tcp and use-udp-membership-messenger are unset or false.
6. Move the JDK to 17 if 10.3 is the target.
7. Roll to 10.2 or 10.3 the same way. For 10.3, upgrade extensions to 2.x and apply the Jakarta, library and WAN filter changes before the first member moves.
8. Upgrade clients and their Spring for GemFire artifacts.

With WAN replication, the guide allows rolling upgrades within each site. We upgrade one site, let it run through normal traffic, then move to the next.

Test plan

• Rehearse each hop on a staging cluster with the same regions, deployed JARs, security manager and WAN topology.
• Run every function, listener, cache loader and writer, and check for class loading errors under isolation.
• Exercise PDX serialization across mixed versions, including during the roll.
• Check client pool settings against the 10.3 minimums.
• Run WAN replication both ways and verify conflict resolution against expected results.
• Restart a member under load and confirm redundancy recovers before the next one stops.
• Confirm dashboards and alerts after the statistics changes.
• Restore a disk store backup into a test cluster.

Rollback

The upgrade guides we reviewed describe no procedure for downgrading a cluster that has fully moved to a new version. Our reading of the warning about starting old processes is that a member can only be returned to the old version while the locators are still on it. After that, the way back is an offline restore of the disk store backups taken before the upgrade, into a cluster running the old version, losing writes made since. Take those backups before each hop, keep both installations on every host, and keep the old client builds in your artifact repository.

Apache Geode

Apache Geode is the open source project GemFire is built from; GemFire 10.3 still ships classes in the org.apache.geode packages. Geode is active and has not moved to the Apache Attic. The Apache Software Foundation announced Geode 2.0 on 12 January 2026, with Java 17 as the minimum and a move to Jakarta EE 10. The latest releases are 2.0.3 and 1.15.5, both from September 2026.

Moving from GemFire to Geode is a migration rather than an upgrade: features that exist only in the commercial product, such as the GemFire Search and Vector Database extensions and the Management Console, need a replacement. The GemFire to Geode use case and Exiting Tanzu cover that route.

If you cannot upgrade yet

A two-hop upgrade with a JDK change and a Jakarta move in the middle does not fit every change calendar, and a 9.15 or 10.0 grid may need to stay where it is for a while. OSSeva covers GemFire 9.x and 10.x, and Apache Geode 1.14, 1.15 and 2.x, with CVE patches as signed artifacts, with serialization flaws handled as a priority class. Assure adds a cluster topology and security configuration audit, a region security and access control review, a WAN replication security review, a SOC 2 and HIPAA attestation package and a GemFire to Geode migration assessment. Operate adds 24/7 cluster health and memory monitoring, a 15-minute P1 response, a named senior GemFire and Geode engineer, eviction and overflow management and execution of the move to Geode. See GemFire and Geode support and the GemFire 9.15 and GemFire 10.0 end-of-life pages.

Common questions

Can I upgrade GemFire 9.15 directly to 10.2 or 10.3?

No. 10.2 removed the UDP communication that 9.x needs, so the path is 9.15 to 10.1.2 or later, then to 10.2 or 10.3.

Can I upgrade GemFire 10.0 directly to 10.3?

Yes. The 10.3 release notes allow any 10.x release to upgrade directly, and a rolling upgrade is possible within the 10.x major version.

Does GemFire 10.3 still run on Java 8 or 11?

No. 10.3 requires JDK 17 or later and supports JDK 17, 21 and 25.

When does GemFire 10.1 reach end of support?

On 28 February 2027, according to Broadcom's lifecycle table. 10.2 is supported until 31 October 2028 and 10.3 until 31 July 2029.

Has Apache Geode been retired?

No. Geode is an active Apache project. Geode 2.0 was announced in January 2026 and 2.0.3 was released in September 2026.