Controlling Socket Use

For peer-to-peer communication, you can manage socket use at the system member level and at the thread level. The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for distributed system member communication. This setting has no effect on communication between a server and its clients or between gateways in multisite installations, but it does control the server’s and gateway’s communication with their peers. The servers and gateway hubs connect to their peers to service requests from clients and remote sites. In client/server settings in particular, where there can be a large number of clients for each server, controlling peer-to-peer socket use is an important part of tuning server performance.

You configure conserve-sockets for the member as a whole in gemfire.properties. Additionally, you can change the sockets conservation policy for the individual thread through the API.

When conserve-sockets is set to false, each application thread uses a dedicated thread to send to each of its peers and a dedicated thread to receive from each peer. Disabling socket conservation requires more system resources, but can potentially improve performance by removing socket contention between threads and optimizing distributed ACK operations. For distributed regions, the put operation, and destroy and invalidate for regions and entries, can all be optimized with conserve-sockets set to false. For partitioned regions, setting conserve-sockets to false can improve general throughput.

You can override the conserve-sockets setting for individual threads. These methods are in com.gemstone.gemfire.distributed.DistributedSystem:
  • setThreadsSocketPolicy. Sets the calling thread’s individual socket policy, overriding the policy set for the application as a whole. If set to true, the calling thread shares socket connections with other threads. If false, the calling thread has its own sockets.
  • releaseThreadsSockets. Frees any sockets held by the calling thread. Threads hold their own sockets only when conserve-sockets is true. Threads holding their own sockets can call this method to avoid holding the sockets until the socket-lease-time has expired.

A typical implementation might set conserve-sockets to true at the application level and then override the setting for the specific application threads that perform the bulk of the distributed operations. The example below shows an implementation of the two API calls in a thread that performs benchmark tests. The example assumes the class implements Runnable. Note that the invocation, setThreadsSocketPolicy(false), is only meaningful if conserve-sockets is set to true at the application level.

public void run() {
	DistributedSystem.setThreadsSocketPolicy(false);
	try {
		// do your benchmark work
	} finally {
		DistributedSystem.releaseThreadsSockets();
	}
}