Understanding Client Single-Hop Access to Server-Partitioned Regions

This topic explains how client single-hop access to server-partitioned regions works in VMware GemFire.

With single-hop access the client connects to every server, so more connections are generally used. This works fine for smaller installations, but is a barrier to scaling. If you have a large installation with many clients, you may want to deactivate single hop by setting the pool attribute pr-single-hop-enabled to false in your pool declarations.

Without single-hop, the client uses the first server connection available. The server that receives the request determines the data location and contacts the host, which might be a different server, so additional requests are made to the server system.

When enabled, single-hop access is used for the following operations:

• put
• get
• destroy
• invalidate
• putAll
• getAll
• removeAll
• onRegion function execution

To perform single-hop data access, clients use metadata from the servers about where the entry buckets are hosted. The metadata is cached locally and maintained ‘lazily’, that is, it is updated only after a single-hop operation attempt requires multiple hops to succeed, an indicator of stale metadata in the client.

When pr-single-hop-enabled is true, the single-hop operations listed above first try to get a direct connection to the server hosting the data. The single-hop request is subject to two timeout intervals, server-connection-timeout and free-connection-timeout:

• The single-hop operation waits for the interval defined by server-connection-timeout (default 0) to get a connection to the desired server.
• If server-connection-timeout elapses without obtaining a connection, the client retries the operation in multi-hop mode, requesting an available connection from any server.
• The multi-hop operation waits for the interval defined by free-connection-timeout (default 10 seconds) to get a free connection to any server.

You can tune these two timeout periods to suit your application’s needs, which may be especially useful if your application has a low max-connection count.

Single Hop and the Pool max-connections Setting

By default, the max-connections parameter is set to -1, which means no maximum is imposed. Setting the parameter to a positive number imposes a limit on the number of connections in the connection pool.

Important

Setting the pool’s max-connections value is not recommended when single-hop is enabled. Limiting the pool’s connections with single-hop can cause connection thrashing, throughput loss, and server log bloat.

If you feel you must set the pool’s max-connections, either deactivate single-hop or keep a close watch on your system for these negative effects.

Setting no limit on connections, however, can result in too many connections to your servers, possibly causing you to run up against your system’s file handle limits. Review your anticipated connection use and make sure your servers are able to accommodate it.

Balancing Single-Hop Server Connection Use

Single-hop gives the biggest benefits when data access is well balanced across your servers. In particular, the loads for client/server connections can get out of balance if you have these in combination:

• Servers that are empty data accessors or that do not host the data the clients access through single-key operations
• Many single-key operations from the clients

If data access is greatly out of balance, clients can thrash trying to get to the data servers. In this case, it might be faster to deactivate single hop and go through servers that do not host the data.