Class CommandQueuePolicy

Policy governing the use of the global command queue.

Which commands are affected by the command queue?

Not all client commands use the command queue. Only single-key commands (e.g. Put, Get, etc.), the BatchRead, BatchWrite commands, and Query#foreach, Scan#foreach commands use the command queue (if enabled).

Commands that are based on the Aerospike info protocol (Index Create/Remove, UDF Register/Remove, Truncate, Info), the legacy Batch Get/Select/Exists commands as well as all other Query and Scan commands do not use the command queue and will always be executed immediately.

* Aerospike.setupGlobalCommandQueue - function used to initialize the global command queue.

const Aerospike = require('aerospike')

const policy = {
maxCommandsInProcess: 50,
maxCommandsInQueue: 150
}
Aerospike.setupGlobalCommandQueue(policy)

Aerospike.connect()
.then(client => {
let commands = []
for (var i = 0; i < 100; i++) {
let cmd = client.put(new Aerospike.Key('test', 'test', i), {i: i})
commands.push(cmd)
}

// First 50 commands will be executed immediately,
// remaining commands will be queued and executed once the client frees up.
Promise.all(commands)
.then(() => console.info('All commands executed successfully'))
.catch(error => console.error('Error:', error))
.then(() => client.close())
})

Hierarchy (view full)

Constructors

Properties

compress?: boolean

Use zlib compression on write or batch read commands when the command buffer size is greater than 128 bytes. In addition, tell the server to compress it's response on read commands. The server response compression threshold is also 128 bytes.

This option will increase cpu and memory usage (for extra compressed buffers), but decrease the size of data sent over the network.

Requires Enterprise Server version >= 4.8.

@default: false

v3.14.0

filterExpression?: AerospikeExp

Optional expression filter. If filter exp exists and evaluates to false, the command is ignored. This can be used to eliminate a client/server roundtrip in some cases.

expression filters can only be applied to the following commands:

maxCommandsInProcess?: number

Maximum number of commands that can be processed at any point in time. Each executing command requires a socket connection. Consuming too many sockets can negatively affect application reliability and performance. If you do not limit command count in your application, this setting should be used to enforce a limit internally in the client.

If this limit is reached, the next command will be placed on the client's command queue for later execution. If this limit is zero, all commands will be executed immediately and the command queue will not be used. (Note: Config#maxConnsPerNode may still limit number of connections per cluster node.)

If defined, a reasonable value is 40. The optimal value will depend on the CPU speed and network bandwidth.

0 (execute all commands immediately)
maxCommandsInQueue?: number

Maximum number of commands that can be stored in the global command queue for later execution. Queued commands consume memory, but they do not consume sockets. This limit should be defined when it's possible that the application executes so many commands that memory could be exhausted.

If this limit is reached, the next command will be rejected with error code ERR_ASYNC_QUEUE_FULL. If this limit is zero, all commands will be accepted into the delay queue.

The optimal value will depend on the application's magnitude of command bursts and the amount of memory available to store commands.

0 (no command queue limit)
maxRetries?: number

Maximum number of retries before aborting the current command. The initial attempt is not counted as a retry.

If maxRetries is exceeded, the command will return error ERR_TIMEOUT.

WARNING: Database writes that are not idempotent (such as "add") should not be retried because the write command may be performed multiple times if the client timed out previous command attempts. It is important to use a distinct write policy for non-idempotent writes which sets maxRetries to zero.

@default: 2 (initial attempt + 2 retries = 3 attempts)

queueInitialCapacity?: number

Initial capacity of the command queue. The command queue can resize beyond this initial capacity.

256 (if command queue is used)
socketTimeout?: number

Socket idle timeout in milliseconds when processing a database command.

If socketTimeout is not zero and the socket has been idle for at least socketTimeout, both maxRetries and totalTimeout are checked. If maxRetries and totalTimeout are not exceeded, the command is retried.

If both socketTimeout and totalTimeout are non-zero and socketTimeout > totalTimeout, then socketTimeout will be set to totalTimeout. If socketTimeout is zero, there will be no socket idle limit.

0 (no socket idle time limit).
totalTimeout?: number

Total command timeout in milliseconds.

The totalTimeout is tracked on the client and sent to the server along with the command in the wire protocol. The client will most likely timeout first, but the server also has the capability to timeout the command

If totalTimeout is not zero and totalTimeout is reached before the command completes, the command will return error ERR_TIMEOUT. If totalTimeout is zero, there will be no total time limit.

1000

Transaction identifier. See Transaction for more information.

null (no transaction)
MMNEPVFCICPMFPCPTTAAATR