Asynchronous connect

You can create a Client instance with the following:

let client = await Aerospike.connect({hosts: '127.0.0.1:3000'})

The Client 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 Client constructor also accepts a host array.

let client = await Aerospike.connect({
  hosts: [
    { addr: "127.0.0.1", port: 3000 },
    { addr: "127.0.0.2", port: 3001 },
    { addr: "127.0.0.3", port: 3002 }
  ]
})

You can also connect and use a callback to handle the client once it has been connected.

Aerospike.connect(config, (error, client) => { /* Add Client code here */ })

Any methods which allow the await keyword are able to return results in a callback optionally.

Close

You can close a Client instance with the following:

await client.close()

The event loop should be closed before program shutdown. If you are using multiple clients and need to persist the event loop, close the client with the releaseEventLoops parameter set to true.

await client.close(true)

Client waits for pending asynchronous commands to complete before closing. Asynchronous commands issued after close() are rejected.

maxCommandsInProcess

The maxCommandsInProcess 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 N commands has gone to a single node, fully occupying that node’s connection pool.

• The next sequence of N commands 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.