Validating the gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS Property in GemFire Clients

Products

• VMware Tanzu Gemfire

Issue/Introduction

When configuring Java microservices that use PDX serialization, you may need to enable the setting:

gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS=true

This property is intended to clear the client-side PDX type registry upon disconnection from a GemFire/Apache Geode cluster.
However, when the application starts, the following warning appears:

[gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS] is not a valid Apache Geode property

Despite the warning, the property still influences client behavior. This article explains the cause of this warning and how to verify that the property works correctly.

Environment

VMware Tanzu GemFire 10.1.X

Cause

Apache Geode/GemFire uses two categories of system properties:

1. Public, documented properties – validated during server or client startup.

2. Internal, undocumented properties – used by internal components but not validated at startup.

gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS belongs to the second category.
Because it is not a public property, the Spring Boot auto-configuration module logs a warning indicating that it is “not a valid Apache Geode property.” This warning is harmless.

Even though the property is not validated, GemFire internally checks this setting later during runtime and applies its behavior to the client pool.

Resolution

The property works as designed and instructs the client to:

Clear its cached PDX type registry whenever it loses connectivity to the GemFire cluster.

To verify the property is functioning, perform the following steps:

1. Start a long-running GemFire client

• Use PROXY regions only, so the client relies on the cluster for metadata.

• Insert PDX-serialized objects (example: User object).

2. Check the client logs for PDX type caching

When the client caches a PDX type for the first time, logs similar to the following appear:

INFO  ... TypeRegistry : Caching PdxType[...]

This confirms the client has stored the PDX type in its local registry.

3. While the client remains running, stop all locator(s) and server(s)

• Restart them normally

4. Wait for the cluster to restart fully

5. Observe the client logs again

After reconnecting, the client should log the same PDX type caching message again:

INFO ... TypeRegistry : Caching PdxType[...]

This second occurrence confirms:

• The client detected the disconnect

• Cleared its local PDX type registry

• Re-cached the PDX type upon reconnecting