Managing Member Groups in Static Tanzu GemFire Environments

Products

• VMware Tanzu Gemfire

Issue/Introduction

In static (non-cluster config) GemFire setups, members can be misidentified or excluded from operations (like gfsh commands or client routing) if group definitions are deprecated or misplaced.

Environment

• Product: All supported versions of VMware Tanzu GemFire 
• Deployment: Static configuration (cache.xml and gemfire.properties)
• Cluster Configuration Service: Disabled (use-cluster-configuration=false)

Cause

• Immutable Groups: Defined only at startup; cannot be changed at runtime.
• Deprecated XML Tags: The <group> tag in cache.xml (pre‑7.x feature) is obsolete and ignored.
• Local Scope: cache.xml defines what to create; gemfire.properties defines who the member is.

Resolution

1. Define Groups Correctly
• Remove all <group> tags from cache.xml.
• Set groups only in:
• System property: -Dgemfire.groups=GroupA,GroupB
• or gemfire.properties: groups=GroupA,GroupB
2. Disk Store Scope
• Disk stores in cache.xml are always created by that member—groups are ignored.
• To restrict by group, deploy different cache.xml files per host.
3. Client‑Server Alignment
• Match client server-group with the server’s group property. Example:
• Client: <pool name="myPool" server-group="DataGroup">
• Server: groups=DataGroup

Additional Information

Best Practices

• Perform a rolling restart to add, remove, or rename groups.
• Remove legacy <group> tags to avoid confusion.
• Group names are case‑sensitive.

References

• GemFire Property: groups
• Organizing Members into Groups
• Client/Server Pool Configuration