Aynchronous Connect
You can create an AerospikeClient instance with assigned event loops.
ClientPolicy clientPolicy = new ClientPolicy();
clientPolicy.eventLoops = eventLoops;
AerospikeClient client = new AerospikeClient(clientPolicy, new Host("host1", 3000), new Host("host2", 3000), new Host("host3", 3000));
AerospikeClient only needs one host to seed the cluster, but using all known hosts for seeds is still recommended because some hosts may be inactive. The AerospikeClient constructor also accepts a host array.
Host[] hosts = new Host[] {new Host("host1", 3000), new Host("host2", 3000), new Host("host3", 3000)};
AerospikeClient client = new AerospikeClient(clientPolicy, hosts);
AerospikeClient can perform both synchronous and asynchronous commands in a single instance. eventLoops is required when performing asynchronous commands. AerospikeClient is thread-safe and can be used concurrently.
Close
Both AerospikeClient and eventLoops should be closed before program shutdown.
client.close()
eventLoops.close();
AerospikeClient waits for pending asynchronous commands to complete before closing.
Asynchronous commands issued after close() are rejected.
Connection tuning
The number of event loops for an EventLoops instance should be approximately the same as
the number of CPU cores on the server that are reserved for AerospikeClient processing.
maxCommandsInProgress
The maxCommandsInProgress parameter
is used to limit the number of concurrent commands allowed on an event loop.
The upper limit for open connections is calculated with the following formula:
(Number of event loops) x (maxCommandsInProcess) x (Number of nodes)
Assuming N = (Number of event loops) x (maxCommandsInProgress),
the upper limit is reached if the following conditions occur:
- A sequence of
Ncommands has gone to a single node, fully occupying that node’s connection pool. - The next sequence of
Ncommands has gone to another node, and so on until the connection pools on all cluster nodes are fully occupied.
The number of open connections on a node can exceed N, because connections are cached
in connection pools (one pool per node per event loop). maxCommandsInProcess
limits the number of concurrently executing commands/connections, but there
are a number of extra connections in each node’s connection pools. These
extra connections in each node are useful because command distribution across
nodes is never exactly evenly distributed. If one node receives a disproportionately
large number of commands, those commands use the extra connections instead of
creating new connections. Every connection pool has these extra connections
to compensate for uneven command distribution among nodes.
maxSocketIdle
The total number of open sockets on a cluster correlates to the number of sockets consumed at peak usage. Connection pools are trimmed when connections in the pool sit unused for longer than the interval specified by ClientPolicy.maxSocketIdle or a timeout/network error occurs on a connection.
maxConnsPerNode
You can limit the number of connections to a node with the
maxConnsPerNode
parameter. However, if the specified limit is reached, the client throws a
NO_MORE_CONNECTIONS exception.
asyncMinConnsPerNode
The Java client starts with a pool of 50 connections distributed over the
configured event loops that are created in the first instance. When one connection
is created another starts immediately afterwards until it reaches the specified value for
asyncMinConnsPerNode.
Creating connections this way establishes the pool with the first 50 connections; further connections are created one by one after the initial burst of 50. This avoids overwhelming the cluster with connection requests on application startup.
Refer to the How to Troubleshoot Async Delay Queue Full Errors Knowledge Base article for more information about event loop and delay queue behavior.