com.avast.sst.datastax.config

The address translator to use to convert the addresses sent by Cassandra nodes into ones that the driver uses to connect. By default com.datastax.oss.driver.internal.core.addresstranslation.PassThroughAddressTranslator is used.

if None no authentication will occur.

The component that coalesces writes on the connections.

Configures query connection.

Configures dedicated administrative connection.

Heartbeat configuration to check if node is alive.

Metadata about the Cassandra cluster.

Metrics configuration. Disabled by default.

Netty configuration which is used internally by driver.

A session-wide component that listens for node state changes. By default com.datastax.oss.driver.internal.core.metadata.NoopNodeStateListener is used.

Prepared statements configuration.

The native protocol to use which defines the format of the binary messages between driver and Cassandra.

Whether to schedule reconnection attempts if all contact points are unreachable on the first initialization attempt. If this is true, the driver will retry according to the reconnection policy. The SessionBuilder.build() call -- or the future returned by SessionBuilder.buildAsync() -- won't complete until a contact point has been reached. If this is false and no contact points are available, the driver will fail.

The policy that controls how often the driver tries to re-establish connections to down nodes.

Request configuration.

A session-wide component that tracks the outcome of requests. By default com.datastax.oss.driver.internal.core.trackerNoopRequestTracker is used.

Whether to resolve the addresses passed to Basic.contactPoints. If this is true, addresses are created with InetSocketAddress(String, int): the host name will be resolved the first time, and the driver will use the resolved IP address for all subsequent connection attempts. If this is false, addresses are created with InetSocketAddress.createUnresolved(): the host name will be resolved again every time the driver opens a new connection. This is useful for containerized environments where DNS records are more likely to change over time (note that the JVM and OS have their own DNS caching mechanisms, so you might need additional configuration beyond the driver).

The policy that controls if the driver retries requests that have failed on one node.

A session-wide component that listens for node state changes. By default com.datastax.oss.driver.internal.core.metadata.schema.NoopSchemaChangeListener is used.

Socket configuration.

The policy that controls if the driver pre-emptively tries other nodes if a node takes too long to respond.

A session-wide component that controls the rate at which requests are executed. By default PassThroughRequestThrottler is used.

The generator that assigns a microsecond timestamp to each request.

Whether logging of server warnings generated during query execution should be disabled by the driver.

Whether a warning is logged when a request (such as a CQL USE ...) changes the active keyspace.

custom class that implements AuthProvider and has a public constructor with a DriverContext argument

The contact points to use for the initial connection to the cluster. These are addresses of Cassandra nodes that the driver uses to discover the cluster topology. Only one contact point is required (the driver will retrieve the address of the other nodes automatically), but it is usually a good idea to provide more than one contact point, because if that single contact point is unavailable, the driver cannot initialize itself correctly. This must be a list of strings with each contact point specified as "host:port". If the host is a DNS name that resolves to multiple A-records, all the corresponding addresses will be used. Do not use "localhost" as the host name (since it resolves to both IPv4 and IPv6 addresses on some platforms). Note that Cassandra 3 and below requires all nodes in a cluster to share the same port (see CASSANDRA-7544).

The policy that decides the "query plan" for each query; that is, which nodes to try as coordinators, and in which order. Overridable in a profile. Note that the driver creates as few instances as possible: if a named profile inherits from the default profile, or if two sibling profiles have the exact same configuration, they will share a single policy instance at runtime. If there are multiple load balancing policies in a single driver instance, they work together in the following way:

• each request gets a query plan from its profile's policy (or the default policy if the request has no profile, or the profile does not override the policy).
• when the policies assign distances to nodes, the driver uses the closest assigned distance for any given node.

This configures basic request properties such as timeout, page size etc.

The name of the keyspace that the session should initially be connected to. This expects the same format as in a CQL query: case-sensitive names must be quoted. If this option is absent, the session won't be connected to any keyspace, and you'll have to either qualify table names in your queries, or use the per-query keyspace feature available in Cassandra 4 and above (see com.datastax.oss.driver.api.core.session.Request.getKeyspace()).

A name that uniquely identifies the driver instance created from this configuration. This is used as a prefix for log messages and metrics. If this option is absent, the driver will generate an identifier composed of the letter 's' followed by an incrementing counter. If you provide a different value, try to keep it short to keep the logs readable. Also, make sure it is unique: reusing the same value will not break the driver, but it will mix up the logs and metrics.

The consistency level. Overridable in a profile.

The default idempotence of a request, that will be used for all Request instances where isIdempotent() returns null. Overridable in a profile.

The page size. This controls how many rows will be retrieved simultaneously in a single network roundtrip (the goal being to avoid loading too many results in memory at the same time). If there are more results, additional requests will be used to retrieve them (either automatically if you iterate with the sync API, or explicitly with the async API's fetchNextPage method). If the value is 0 or negative, it will be ignored and the request will not be paged. Overridable in a profile.

The serial consistency level. The allowed values are SERIAL and LOCAL_SERIAL. Overridable in a profile.

How long the driver waits for a request to complete. This is a global limit on the duration of a session.execute() call, including any internal retries the driver might do. By default, this value is set pretty high to ensure that DDL queries don't time out, in order to provide the best experience for new users trying the driver with the out-of-the-box configuration. For any serious deployment, we recommend that you use separate configuration profiles for DDL and DML; you can then set the DML timeout much lower (down to a few milliseconds if needed). Note that, because timeouts are scheduled on the driver's timer thread, the duration specified here must be greater than the timer tick duration defined by the advanced.netty.timer.tick-duration setting (see below). If that is not the case, timeouts will not be triggered as timely as desired. Overridable in a profile.

The reschedule interval.

The timeout to use for internal queries that run as part of the initialization process. If this timeout fires, the initialization of the connection will fail. If this is the first connection ever, the driver will fail to initialize as well, otherwise it will retry the connection later.

The driver maintains a connection pool to each node

The maximum number of "orphaned" requests before a connection gets closed automatically.

The maximum number of requests that can be executed concurrently on a connection. This must be between 1 and 32768.

The driver maintains a connection pool to each node

The timeout to use when the driver changes the keyspace on a connection at runtime.

Whether to log non-fatal errors when the driver tries to open a new connection.

The largest latency that we expect to record.

The interval at which percentile data is refreshed.

The number of significant decimal digits to which internal structures will maintain value resolution and separation (for example, 3 means that recordings up to 1 second will be recorded with a resolution of 1 millisecond or better). This must be between 0 and 5. If the value is out of range, it defaults to 3 and a warning is logged.

The maximum number of refreshes that can accumulate. If this count is reached, a refresh is done immediately and the window is reset.

How long the driver waits to apply a refresh. If another refresh is requested within that time, the window is reset and a single refresh will be triggered when it ends. Debouncing may be disabled by setting the window to 0 or max-events to 1 (this is highly discouraged for schema refreshes).

How often the warning will be logged if timestamps keep drifting above the threshold.

How far in the future timestamps are allowed to drift before the warning is logged. If it is undefined or set to 0, warnings are disabled.

it must be the fully-qualified name of a class that implements java.util.function.Predicate<Node>, and has a public constructor taking a single DriverContext argument.

The options to shut down the event loop group gracefully when the driver closes. If a task gets submitted during the quiet period, it is accepted and the quiet period starts over. The timeout limits the overall shutdown time.

The number of threads. If this is set to 0, the driver will use Runtime.getRuntime().availableProcessors() * 2.

The heartbeat interval

How long the driver waits for the response to a heartbeat. If this timeout fires, the heartbeat is considered failed.

The class of the policy. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.loadbalancing.

A custom filter to include/exclude nodes.

The datacenter that is considered "local": the default policy will only include nodes from this datacenter in its query plans. This option can only be absent if you specified no contact points: in that case, the driver defaults to 127.0.0.1:9042, and that node's datacenter is used as the local datacenter. As soon as you provide contact points (either through the configuration or through the cluster builder), you must define the local datacenter explicitly, and initialization will fail if this property is absent. In addition, all contact points should be from this datacenter; warnings will be logged for nodes that are from a different one.

Whether to log failed requests.

The maximum length of the query string in the log message. If it is longer than that, it will be truncated.

The maximum length for bound values in the log message. If the formatted representation of a value is longer than that, it will be truncated.

The maximum number of bound values to log. If a request has more values, the list of values will be truncated.

Whether to log stack traces for failed queries. If this is disabled, the log will just include the exception's string representation (generally the class name and message).

Whether to log bound values in addition to the query string.

Slow requests logging.

Whether to log successful requests.

Debouncing to smoothen out oscillations if conflicting events are sent out in short bursts.

Options relating to schema metadata.

Whether token metadata (Cluster.getMetadata.getTokenMap) is enabled.

The node-level metrics (all disabled by default).

The session-level metrics (all disabled by default).

The event loop group used for admin tasks not related to request I/O (handle cluster events, refresh metadata, schedule reconnections, etc.) By default, threads in this group are named after the session name, "-admin-" and an incrementing counter, for example "s0-admin-0".

Whether the threads created by the driver should be daemon threads. This will apply to the threads in io-group, admin-group, and the timer thread.

The event loop group used for I/O operations (reading and writing to Cassandra nodes). By default, threads in this group are named after the session name, "-io-" and an incrementing counter, for example "s0-io-0".

The timer used for scheduling request timeouts and speculative executions By default, this thread is named after the session name and "-timer-0", for example "s0-timer-0".

Required: if the 'cql-messages' metric is enabled

node-level metrics

The number of connections in the pool

Overridable in a profile.

The name of the algorithm used to compress protocol frames.

The maximum length of the frames supported by the driver in megabytes. Beyond that limit, requests will fail with an exception.

The native protocol version to use. If this option is absent, the driver looks up the versions of the nodes at startup (by default in "system.peers.release_version"), and chooses the highest common protocol version.

Reconnection policy starts with the base delay.

The class of the policy. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.connection.

Reconnection policy increases delay up to the max delay.

Whether to check system.prepared_statements on the target node before repreparing. This table exists since CASSANDRA-8831 (merged in 3.10). It stores the statements already prepared on the node, and preserves them across restarts. Checking the table first avoids repreparing unnecessarily, but the cost of the query is not always worth the improvement, especially if the number of statements is low. If the table does not exist, or the query fails for any other reason, the error is ignored and the driver proceeds to reprepare statements according to the other parameters.

Whether the driver tries to prepare on new nodes at all. The reason why you might want to disable it is to optimize reconnection time when you believe nodes often get marked down because of temporary network issues, rather than the node really crashing. In that case, the node still has prepared statements in its cache when the driver reconnects, so re-preparing is redundant. On the other hand, if that assumption turns out to be wrong and the node had really restarted, its prepared statement cache is empty (before CASSANDRA-8831), and statements need to be re-prepared on the fly the first time they get executed; this causes a performance penalty (one extra roundtrip to resend the query to prepare, and another to retry the execution).

The maximum number of concurrent requests when repreparing.

The maximum number of statements that should be reprepared. 0 or a negative value means no limit.

The request timeout. This applies both to querying the system.prepared_statements table (if relevant), and the prepare requests themselves.

The class of the tracker. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.tracker.

Parameters for RequestLogger

The class of the policy. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.retry.

The interval between each attempt.

The timeout after which schema agreement fails. If this is set to 0, schema agreement is skipped and will always fail.

Whether to log a warning if schema agreement fails. You might want to change this if you've set the timeout to 0.

Protects against bursts of schema updates.

Whether schema metadata is enabled. If this is false, the schema will remain empty, or to the last known value.

The list of keyspaces for which schema and token metadata should be maintained. If this property is absent or empty, all existing keyspaces are processed.

The page size for the requests to the schema tables.

The timeout for the requests to the schema tables.

Extra configuration (for the metrics that need it). Required if the 'cql-requests' metric is enabled

The session-level metrics (all disabled by default).

Configures request throttling metrics..

Whether to log slow requests.

The threshold to classify a successful request as "slow". If this is unset, all successful requests will be considered as normal.

All other socket options are unset by default. The actual value depends on the underlying Netty transport.

Sets the linger interval. If the value is zero or greater, then it represents a timeout value, in seconds; if the value is negative, it means that this option is disabled.

Sets a hint to the size of the underlying buffers for incoming network I/O.

Whether or not to allow address reuse.

Sets a hint to the size of the underlying buffers for outgoing network I/O.

Whether or not to disable the Nagle algorithm. By default, this option is set to true (Nagle disabled), because the driver has its own internal message coalescing algorithm.

The class of the policy. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.specex.

The delay between each execution. 0 is allowed, and will result in all executions being sent simultaneously when the request starts.

The maximum number of executions (including the initial, non-speculative execution). This must be at least one.

The class of the throttler. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.session.throttling.

How often the throttler attempts to dequeue requests. Only used by RateLimitingRequestThrottler.

The maximum number of requests that are allowed to execute in parallel. Only used by ConcurrencyLimitingRequestThrottler.

The maximum number of requests that can be enqueued when the throttling threshold is exceeded. Beyond that size, requests will fail with a RequestThrottlingException.

The maximum allowed request rate. Only used by RateLimitingRequestThrottler.

This is the time between the start of the session.execute() call, and the moment when the throttler allows the request to proceed. Required: if the 'throttling.delay' metric is enabled

The timer tick duration. This is how frequent the timer should wake up to check for timed-out tasks or speculative executions. Lower resolution (i.e. longer durations) will leave more CPU cycles for running I/O operations at the cost of precision of exactly when a request timeout will expire or a speculative execution will run. Higher resolution (i.e. shorter durations) will result in more precise request timeouts and speculative execution scheduling, but at the cost of CPU cycles taken from I/O operations, which could lead to lower overall I/O throughput. The default value is 100 milliseconds, which is a comfortable value for most use cases. However if you are using more agressive timeouts or speculative execution delays, then you should lower the timer tick duration as well, so that its value is always equal to or lesser than the timeout duration and/or speculative execution delay you intend to use. Note for Windows users: avoid setting this to aggressive values, that is, anything under 100 milliseconds; doing so is known to cause extreme CPU usage. Also, the tick duration must be a multiple of 10 under Windows; if that is not the case, it will be automatically rounded down to the nearest multiple of 10 (e.g. 99 milliseconds will be rounded down to 90 milliseconds).

Number of ticks in a Timer wheel. The underlying implementation uses Netty's HashedWheelTimer, which uses hashes to arrange the timeouts. This effectively controls the size of the timer wheel.

The class of the generator. If it is not qualified, the driver assumes that it resides in the package com.datastax.oss.driver.internal.core.time.

configure timestamp drift logging

Whether to force the driver to use Java's millisecond-precision system clock. If this is false, the driver will try to access the microsecond-precision OS clock via native calls (and fallback to the Java one if the native calls fail).

The maximum number of events that can accumulate. If this count is reached, the events are delivered immediately and the time window is reset. This avoids holding events indefinitely if the window keeps getting reset.

How long the driver waits to propagate an event. If another event is received within that time, the window is reset and a batch of accumulated events will be delivered. Debouncing may be disabled by setting the window to 0 or max-events to 1 (not recommended).

How many times the driver will attempt to fetch the query if it is not ready yet.

The consistency level to use for trace queries.

The interval between each attempt.