Configuring a Client/Server System

This topic explains how to configure a VMware Tanzu GemFire client/server system. Use this topic to configure your server processes, client processes, and data regions to run your client/server system.

Prerequisites

Configure your server system using locators for member discovery. See Configuring Peer-to-Peer Discovery and Managing a Peer or Server Cache.
Configure your clients as standalone applications. See Managing a Client Cache.
Be familiar with cache region configuration. See Data Regions.
Be familiar with server and client configuration properties. See cache.xml.

Procedure

Configure servers to listen for clients by completing one or both of the following tasks.
- Configure each application server as a server by specifying the <cache-server> element in the application’s cache.xml and optionally specifying a non-default port to listen on for client connections.
  
  For example:
```
<cache-server port="40404" ... />
```
- Optional. Configure each cacheserver process with a non-default port to listen on for client connections.
  
  For example:
```
prompt> cacheserver start -port="44454"
```
Configure clients to connect to servers. In the client cache.xml, use the server system’s locator list to configure your client server pools and configure your client regions to use the pools. For example:
```
<client-cache>
   <pool name="publisher" subscription-enabled="true">
      <locator host="lucy1" port="41111"/>
      <locator host="lucy2" port="41111"/>
   </pool>
   ...
   <region name="clientRegion" ...
      <region-attributes pool-name="publisher" ...
```
You do not need to provide the complete list of locators to the clients at startup, but you should provide as complete a list as possible. The locators maintain a dynamic list of locators and servers and provide the information to the clients as needed.

When TLS (SSL) is used clients can also be directed to go through a SNI gateway such as Istio or HAProxy to reach locators and servers. To do this add the following to your cache.xml pool configuration: <pool… > org.apache.geode.cache.client.proxy.SniProxySocketFactory my-gateway-address 12345
Configure the server data regions for client/server work, following these guidelines. These do not need to be performed in this order.
- Configure your server regions as partitioned or replicated, to provide a coherent cache view of server data to all clients.
  Note
  If you do not configure your server regions as partitioned or replicated, you can get unexpected results with calls that check server region contents, such as keySetOnServer and containsKeyOnServer. You might get only partial results, and you might also get inconsistent responses from two consecutive calls. These results occur because the servers report only on their local cache content and, without partitioned or replicated regions, they might not have a complete view of the data in their local caches.
- When you define your replicated server regions, use any of the REPLICATE RegionShortcut settings except for REPLICATE_PROXY. Replicated server regions must have distributed-ack or global scope, and every server that defines the region must store data. The region shortcuts use distributed-ack scope and all non-proxy settings store data.
- When you define your partitioned server regions, use the PARTITION RegionShortcut options. You can have local data storage in some servers and no local storage in others.

When you start the server and client systems, the client regions will use the server regions for cache misses, event subscriptions, querying, and other caching activities.

What to do next

Configure your clients to use the cache and to subscribe to events from the servers as needed by your application. See Configuring Client/Server Event Messaging.