How to Set ClientPolicy such as maxThreads, timeout and maxSocketIdle

The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.

#Synopsis Best practices to customer on setting ClientPolicy on their client applications

See java docs for starters: http://www.aerospike.com/apidocs/java/

The synchronous AerospikeClient relies on the caller to generate threads, but AerospikeClient does need to create pools of sockets. Since we want 1 socket per thread (for a given node), maxThreads just sets a limit on the number of sockets in the pool. For performance reasons, you should avoid generating more threads than your specified maxThreads (default: 300).

ClientPolicy.Timeout (in milliseconds) is used as a socket connect timeout only (not a transaction timeout).

maxSocketIdle (seconds) defines how long a socket can sit idle in the connection pool. If the socket is idle for more than maxSocketIdle, it will be closed.

failIfNotConnected is used for app-server implementations that may start before the Aerospike server is started. If failIfNotConnected is false (default), no exception is thrown and the client will automatically connect when Aerospike server is available. If failIfNotConnected is true, an exception will be thrown immediately if Aerospike server is not available.

Recommend using default values.