TxnVerifyPolicy Class

Default: null

For batch commands with smaller sized records (<= 1K per record), inline processing will be significantly faster on in-memory namespaces.

Inline processing can introduce the possibility of unfairness because the server can process the entire batch before moving onto the next command.

Default: true

Inline processing can introduce the possibility of unfairness because the server can process the entire batch before moving onto the next command.

Default: false

This variable is currently only used in batch read/exists operations. For batch, this variable should only be set to true when the replication factor is greater than or equal to the number of nodes in the cluster.

Default: false

This compression feature requires the Enterprise Edition Server.

Default: false

This field is not applicable to batch, scan or query commands.

Default: false

Default: null

The batch is split into requests for each node according to the node assignment of each batch key. The number of batch node requests is always less or equal to the cluster size.

If there are 16 batch node requests and maxConcurrentThreads is 8, then batch requests will be made for 8 nodes in parallel threads. When a request completes, a new request will be issued until all 16 requests are complete. If there are 4 batch node requests and maxConcurrentThreads is 8, then only 4 batch requests will be made for 4 nodes in parallel threads.

Values:

• 1 (default): Issue batch node requests sequentially. This mode has a performance advantage for small batch sizes because requests can be issued in the main command thread without using a thread pool. This mode is not optimal for batch requests spread out over many nodes in a large cluster.
• 0: Issue all batch node requests in parallel threads. This mode has a performance advantage for large batch sizes because each node can process the request immediately. The downside is extra threads will need to be created (or taken from a thread pool). In extreme cases, the operating system's thread capacity could be exhausted.
• > 0: Issue up to maxConcurrentThreads batch node requests in parallel threads. When a request completes, a new request will be issued until all requests are complete. This mode prevents too many parallel threads being created for large clusters. The downside is extra threads will still need to be created (or taken from a thread pool). A typical value is the number of cpu cores available on the client machine.

Default: 1

If maxRetries is exceeded, the command will abort with AerospikeException.Timeout.

WARNING: Database writes that are not idempotent (such as Add()) should not be retried because the write operation may be performed multiple times if the client timed out previous command attempts. It's important to use a distinct WritePolicy for non-idempotent writes which sets maxRetries = 0;

Default for write: 0 (no retries)

Default for read: 2 (initial attempt + 2 retries = 3 attempts)

Default for scan/query: 5 (6 attempts. See ScanPolicy() comments.)

Default: ONE

Default: SESSION

For example, if the most recent write had a TTL of 10 hours and read_touch_ttl_percent is set to 80, the next read within 8 hours of the record's end of life (equivalent to 2 hours after the most recent write) will result in a touch, resetting the TTL to another 10 hours.

Values:

• 0 : Use server config default-read-touch-ttl-pct for the record's namespace/set.
• -1 : Do not reset record TTL on reads.
• 1 - 100 : Reset record TTL on reads when within this percentage of the most recent write TTL.

Default: 0

Default: Use standard record parser.

Default: SEQUENCE

If true, every batch key is attempted regardless of previous key specific errors. Node specific errors such as timeouts stop keys to that node, but keys directed at other nodes will continue to be processed.

If false, the server will stop the batch to its node on most key specific errors. The exceptions are KEY_NOT_FOUND_ERROR and FILTERED_OUT which never stop the batch. The client will stop the entire batch on node specific errors for sync commands that are run in sequence (maxConcurrentThreads == 1). The client will not stop the entire batch for async commands or sync commands run in parallel.

Server versions < 6.0 do not support this field and treat this value as false for key specific errors.

Default: true

If the key is sent on a read, the server will generate the hash digest from the key and vildate that digest with the digest sent by the client. Unless this is the explicit intent of the developer, avoid sending the key on reads.

Default: false (do not send the user defined key)

The sleep only occurs on connection errors and server timeouts which suggest a node is down and the cluster is reforming. The sleep does not occur when the client's socketTimeout expires.

Reads do not have to sleep when a node goes down because the cluster does not shut out reads during cluster reformation. The default for reads is zero.

The default for writes is also zero because writes are not retried by default. Writes need to wait for the cluster to reform when a node goes down. Immediate write retries on node failure have been shown to consistently result in errors. If maxRetries is greater than zero on a write, then sleepBetweenRetries should be set high enough to allow the cluster to reform (>= 3000ms).

Default: 0 (do not sleep between retries)

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

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.

For synchronous methods, socketTimeout is the socket SendTimeout and ReceiveTimeout. For asynchronous methods, the socketTimeout is implemented using the AsyncTimeoutQueue and socketTimeout is only used if totalTimeout is not defined.

Default: 30000ms

When a command is stopped prematurely, the socket must be drained of all incoming data or closed to prevent unread socket data from corrupting the next command that would use that socket.

If a socket read timeout occurs and timeoutDelay is greater than zero, the socket will be drained until all data has been read or timeoutDelay is reached. If all data has been read, the socket will be placed back into the connection pool. If timeoutDelay is reached before the draining is complete, the socket will be closed.

Sync sockets are drained in the cluster tend thread at periodic intervals. timeoutDelay is not supported for async sockets.

Many cloud providers encounter performance problems when sockets are closed by the client when the server still has data left to write (results in socket RST packet). If the socket is fully drained before closing, the socket RST performance penalty can be avoided on these cloud providers.

The disadvantage of enabling timeoutDelay is that extra memory/processing is required to drain sockets and additional connections may still be needed for command retries.

If timeoutDelay were to be enabled, 3000ms would be a reasonable value.

Default: 0 (no delay, connection closed on timeout)

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 abort with AerospikeException.Timeout.

If totalTimeout is zero, there will be no total time limit.

Default for scan/query: 0 (no time limit)

Default for all other commands: 1000ms