KineticaOptions

URL of the primary cluster in the HA environment

Username for authentication

Password for authentication

OAuth2 token for authentication. When set, it is sent as a Bearer token in place of the username and password.

Regex pattern to filter URLs by hostname/IP

Whether to Snappy-compress requests to the endpoints that carry bulk record payloads — /insert/records and /update/records.

This is a switch over an opt-in set, not a global one: every other endpoint is sent uncompressed whatever this is set to, because compressing a small request costs more than it saves.

Whether to bypass SSL certificate verification

The trust store HTTPS connections trust: a PKCS#12 or JKS file, or a PEM file of certificates. Used when its password is given too and certificates are checked. A server whose own certificate is in it, or whose chain leads to one in it, is trusted, and its name is not checked.

The password of the trust store.

Whether to disable failover upon failures

Whether to disable automatic discovery of clusters and worker ranks

Order in which to failover to backup clusters

Additional HTTP headers sent with each request.

The headers the client sets itself (Authorization, Content-type, User-Agent and X-Kinetica-Group) are not sent from here. Basic credentials in an Authorization header are used in place of the username and password, and an X-Kinetica-Group header names the HA synchronicity mode, by its value on the wire or its HaSynchronicityMode constant name (REPL_SYNC or SYNCHRONOUS).

The client program’s name, reported first in the User-Agent header.

The client program’s version, reported with its name.

The server session the connection’s SQL #name temp tables belong to, so that several connections can share one session’s temp tables.

The caller must drop that session, with Kinetica::drop_session on a connection given the same session ID; Kinetica::close does not. If None or empty (the default), each connection has a session of its own, which its close drops.

Whether connections send TCP keep-alive probes, with the operating system’s timings unless set below (default true).

Seconds a connection idles before the first keep-alive probe; 0 (the default) keeps the system’s, typically 7200 on Linux.

Seconds between keep-alive probes; 0 (the default) keeps the system’s, typically 75 on Linux.

Keep-alive probes before a connection is dropped; 0 (the default) keeps the system’s, typically 9 on Linux.

Request timeout in milliseconds (0 = infinite).

A read timeout: it bounds the wait for a response once the request has been sent, and then each read of the response body, never the upload or the body as a whole. So a large request or response that keeps moving is not cut off, while a server that goes quiet for this long is given up on. A timeout waiting for a response is treated like an unreachable server and triggers HA failover.

Timeout for establishing a connection, in milliseconds (0 = infinite)

Host manager port number

Initial connection attempt timeout in milliseconds (0 = no retry)

Maximum number of requests in flight across all hosts (default 40). At least 1.

A request beyond the limit waits up to 5 minutes for a free connection and then fails as a connection error. High-concurrency callers such as a BulkInserter with many workers should raise this to match.

Maximum number of requests in flight to one host (default 10), and the number of idle connections kept per host for reuse. At least 1.

A request beyond the limit waits as for max_total_connections. A BulkInserter with more than this many flush workers sending to one host is throttled to this many concurrent requests.

How many times a request is retried at once, on the same server, when sending it fails or the server answers 502 or 503 (default 5); see HttpClientConfig::max_retries.

How often, in seconds, to check whether the primary cluster is back after an HA failover has moved the connection off it (default 5). Once it passes, the connection fails back to it; see the failback module.