How to avoid PDX conflicts when accessing different clusters from same client

Products

• VMware Tanzu Gemfire

Issue/Introduction

This article describes details about PDX and how to avoid PDX conflicts when accessing several clusters from one client and applies to GemFire.

Resolution

Clients are already designed to simultaneously handle multiple versions of class's PDXType. You will of course need to follow the rules to retain forwards/backwards compatibility to avoid conflicts. The client doesn't juggle multiple sets of metadata for each PDX Type. Rather, it creates its own based on startup/runtime reflection on the local version of the class, populates concrete instances of the class from any PDXInstance it receives, and generates PDXInstance instances for transmission to servers based on the the local definition as well. The client does retain/retransmit any unknown field/value pairs received from a server, even though they are basically invisible to the client.

The metadata is shared throughout the client cache.

If you configure pools pointing to two different clusters there is a chance that it can cause PDX conflict or mismatches. How to avoid that?

The important thing in this scenario is to make sure the different clusters have different values for distributed-system-id. As long as you do that the two different clusters won't assign the same PDX type id to the different classes - because the distributed-system-id becomes part of the PDX type id.

Additional Information

Applies To

GemFire