GemFire Support Options: Broadcom Scope, Apache Geode and Independent

GemFire support comes from Broadcom for licensed VMware Tanzu GemFire customers, within a published scope that covers the product and excludes your application, your JVM and your infrastructure. Independent providers cover what that scope leaves out, and Apache Geode has community support only.

What Broadcom GemFire support covers

Broadcom publishes a scope of support for VMware GemFire products. In scope: issues found during installation, issues with GemFire clients or APIs, diagnosis of issues with GemFire binaries, troubleshooting production performance problems specific to GemFire, bug reports and fixes, and limited help with JVM tuning.

What it excludes

The same article lists what is out of scope: debugging custom code or applications, compiler errors and warnings, load, performance or stress testing beyond a quick health check, third-party products and add-ons, JDK or operating system issues, infrastructure and environment problems, developer tools and plugins, and application architecture guidance, which is referred to professional services.

That is a normal boundary for a product vendor. It is also where most GemFire incidents live. A member that drops out of the cluster during a long garbage collection pause is a JVM heap problem. A slow region is often a serialization or data model decision in application code. A WAN gateway queue that backs up is usually the network.

Versions and Java

Tanzu GemFire 10 runs on JDK 8, 11, 17 and 21, with JDK 11 preferred from version 10.0, per Broadcom's Java support documentation. Broadcom lists end of general support and end of technical guidance dates for each GemFire version in its product lifecycle matrix on the support portal. If you are on GemFire 9.x, check those dates before you plan anything else.

Apache Geode

GemFire 9.x was built on Apache Geode, the open-source project the GemFire code was donated to; the 9.15 release notes describe it as incorporating Geode 1.13 to 1.15. Geode itself has no vendor support. If you run Geode in production, support comes from your own team or an independent provider.

What a GemFire support case needs

Whoever you call, the quality of the answer depends on the data. For a production issue on a VMware Tanzu GemFire cluster that means the logs and statistics files from every member and locator, the cluster configuration, the JVM version and heap and garbage collection settings, thread dumps taken during the problem, and the client configuration if the application is involved. Capture them before restarting anything. A restart clears the evidence, and on a large system a full restart is slow enough to be its own incident.

Where independent GemFire support fits

• The out-of-scope list above: application code, JVM and garbage collection tuning, the operating system, the network between sites.
• GemFire versions past end of general support and Apache Geode deployments.
• Operations: slow full-cluster restarts and disk store recovery, locator and membership problems, region eviction and heap sizing, client configuration.
• Architecture, including whether an in-memory data grid is still the right technology for the workload.

AceMQ provides 24/7 GemFire support with a 15-minute emergency SLA and named senior engineers, for Tanzu GemFire and Apache Geode. A common first step is a cluster architecture assessment.

The GemFire incidents that actually page people

• Members forced out of the cluster. A long garbage collection pause stops a member responding to membership checks, the cluster removes it, and its data has to be recovered and rebalanced while clients see errors. Heap sizing, the collector in use and the member timeout have to be tuned together.
• Slow full-cluster restarts. Persistent regions recover from disk stores, and members wait for the one holding the latest data. A restart in the wrong order can leave the cluster waiting indefinitely, and disk store compaction decides how long recovery takes.
• WAN gateway queues backing up. Replication between sites slows because of bandwidth, a slow receiver or large batches. The queue grows in memory or overflows to disk, and the sites drift apart.
• Eviction and critical heap thresholds. When heap use crosses the critical threshold the resource manager refuses writes. Eviction settings, region sizing and off-heap storage are the levers.
• Serialization mismatches. PDX type registries that differ between sites or versions, and domain classes that changed without a compatible serializer, produce errors that look like data corruption and are not.

Upgrading from GemFire 9 to GemFire 10

GemFire supports rolling upgrades, locators first and then servers, so a cluster can move versions without a full outage if the procedure is followed and the versions are compatible. GemFire 10 raised the Java baseline options and changed packaging, and the Spring integration moved to Spring for VMware GemFire artifacts, so application builds need updating alongside the servers. Clients can generally stay on an older version than the servers for a period, which lets you upgrade the cluster first. Rehearse the rolling upgrade in a test environment with production-sized persistent data, because recovery time per member is what determines how long the real one takes.