# Reference configuration for the DataStax Java driver for Apache Cassandra®.

#

# Unless you use a custom mechanism to load your configuration (see DriverContext), all the values

# declared here will be used as defaults if you don't override them in your own `application.conf`.

#

# Unless explicitly stated otherwise:

# - options are required;

# - they can not be overridden in a profile;

# - runtime changes are ignored.

#

# This file is in HOCON format, see https://github.com/typesafehub/config/blob/master/HOCON.md.

datastax-java-driver {

# 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 the current version of Cassandra (3.11) requires all nodes in a cluster to share the

# same port.

#

# This option is not required. Contact points can also be provided programmatically when you build

# a cluster instance. If both are specified, they will be merged. If both are absent, the driver

# will default to 127.0.0.1:9042.

// contact-points = [ "127.0.0.1:9042", "127.0.0.2:9042" ]

protocol {

# The native protocol version to use.

#

# This option is not required. If it 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. For example, if you have a mixed cluster with Apache Cassandra 2.1 nodes (protocol

# v3) and Apache Cassandra 3.0 nodes (protocol v3 and v4), then protocol v3 is chosen. If the

# nodes don't have a common protocol version, initialization fails.

#

# If this option is set, then the given version will be used for all connections, without any

# negotiation or downgrading. If any of the contact points doesn't support it, it will be

# skipped.

#

# Once the protocol version is set, it can't change for the rest of the driver's lifetime; if an

# incompatible node joins the cluster later, connection will fail and the driver will force it

# down (i.e. never try to connect to it again).

#

# You can check the actual version at runtime with Cluster.getContext().protocolVersion().

// version = V4

# The maximum length of the frames supported by the driver. Beyond that limit, requests will

# fail with an exception

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

max-frame-length = 256 MB

# The components that handles authentication on each new connection.

auth-provider {

# This property is optional; if it is not present, no authentication will occur.

// class = com.datastax.oss.driver.api.core.auth.PlainTextAuthProvider

# Sample configuration for the plain-text provider:

// username = cassandra

// password = cassandra

# Whether to log a warning if an authentication provider is configured on the driver side, but

# the server does not issue an authentication challenge (i.e. lets the driver connect without

# any form of authentication).

#

# This is intended as a help to detect server configuration issues. The warning will be logged

# for every faulty node, and each time a new connection is created.

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

warn-if-no-server-auth = true

}

# The compressor to use for protocol frames.

# The driver provides two built-in implementations for the algorithms supported by Cassandra:

# - com.datastax.oss.driver.internal.core.protocol.Lz4Compressor

# Requires org.xerial.snappy:snappy-java in the classpath.

# - com.datastax.oss.driver.internal.core.protocol.SnappyCompressor

# Requires net.jpountz.lz4:lz4 in the classpath.

#

# The driver depends on the compression libraries, but they are optional. Make sure you

# redeclare an explicit dependency in your project. Refer to the driver's POM or manual for the

# exact version.

#

# If this property is absent, protocol frames are not compressed.

// compressor.class =

}

# A name that uniquely identifies the driver instance created from this configuration. This is

# used as a prefix for log messages and metrics.

# This option is not required; if it is not specified, 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.

// session-name = my_session

# 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 (note that

# the quotes must be escaped in HOCON format). For example:

# session-keyspace = case_insensitive_name

# session-keyspace = \"CaseSensitiveName\"

#

# This option is not required; if it is left unspecified, 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 Request.getKeyspace()).

#

# This can also be provided programatically in CqlSessionBuilder.

// session-keyspace = my_keyspace

# How often the driver tries to reload the configuration.

# This option is required, except if you use a different config loader than the driver's built-in

# one. Runtime changes are taken into account.

# To disable periodic reloading, set this to 0.

config-reload-interval = 5 minutes

# The policy that decides the "query plan" for each query; that is, which nodes to try as

# coordinators, and in which order.

load-balancing-policy {

class = com.datastax.oss.driver.internal.core.loadbalancing.DefaultLoadBalancingPolicy

# 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.

// local-datacenter = datacenter1

# A custom filter to include/exclude nodes.

#

# This option is not required; if present, 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 predicate's `filter(Node)` method will be invoked each time the

# policy processes a topology or state change: if it returns false, the node will be set at

# distance IGNORED (meaning the driver won't ever connect to it), and never included in any

# query plan.

// filter.class=

}

connection {

# The timeout to use for internal queries that run as part of the initialization process, just

# after we open a connection. 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.

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

init-query-timeout = 500 milliseconds

# The timeout to use when the driver changes the keyspace on a connection at runtime (this

# happens when the client issues a `USE ...` query, and all connections belonging to the

# current session need to be updated).

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

set-keyspace-timeout = ${datastax-java-driver.connection.init-query-timeout}

# The maximum number of requests that can be executed concurrently on a connection. This must be

# between 1 and 32768.

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

max-requests-per-connection = 1024

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

#

# Sometimes the driver writes to a node but stops listening for a response (for example if the

# request timed out, or was completed by another node). But we can't safely reuse the stream id

# on this connection until we know for sure that the server is done with it. Therefore the id is

# marked as "orphaned" until we get a response from the node.

#

# If the response never comes (or is lost because of a network issue), orphaned ids can

# accumulate over time, eventually affecting the connection's throughput. So we monitor them and

# close the connection above a given threshold (the pool will replace it).

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

max-orphan-requests = 24576

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

#

# This error as recoverable, as the driver will try to reconnect according to the reconnection

# policy. Therefore some users see them as unnecessary clutter in the logs. On the other hand,

# those logs can be handy to debug a misbehaving node.

#

# This option can be changed at runtime, the new value will be used for new connections created

# after the change.

#

# Note that some type of errors are always logged, regardless of this option:

# - protocol version mismatches (the node gets forced down)

# - when the cluster name in system.local doesn't match the other nodes (the node gets forced

# down)

# - authentication errors (will be retried)

warn-on-init-error = true

heartbeat {

# The heartbeat interval. If a connection stays idle for that duration (no reads), the driver

# sends a dummy message on it to make sure it's still alive. If not, the connection is

# trashed and replaced.

#

# This option can be changed at runtime, the new value will be used for new connections

# created after the change.

interval = 30 seconds

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

# heartbeat is considered failed.

#

# This option can be changed at runtime, the new value will be used for heartbeat queries

# issued after the change.

timeout = ${datastax-java-driver.connection.init-query-timeout}

}

reconnection-policy {

class = com.datastax.oss.driver.api.core.connection.ExponentialReconnectionPolicy

base-delay = 1 second

max-delay = 60 seconds

}

control-connection {

# How long the driver waits for responses to control queries (e.g. fetching the list of

# nodes, refreshing the schema).

timeout = 500 milliseconds

# Due to the distributed nature of Cassandra, schema changes made on one node might not be

# immediately visible to others. Under certain circumstances, the driver waits until all nodes

# agree on a common schema version (namely: before a schema refresh, before repreparing all

# queries on a newly up node, and before completing a successful schema-altering query).

# To do so, it queries system tables to find out the schema version of all nodes that are

# currently UP. If all the versions match, the check succeeds, otherwise it is retried

# periodically, until a given timeout.

#

# A schema agreement failure is not fatal, but it might produce unexpected results (for

# example, getting an "unconfigured table" error for a table that you created right before,

# just because the two queries went to different coordinators).

#

# Note that schema agreement never succeeds in a mixed-version cluster (it would be

# challenging because the way the schema version is computed varies across server versions);

# the assumption is that schema updates are unlikely to happen during a rolling upgrade

# anyway.

schema-agreement {

# The interval between each attempt.

# This option can be changed at runtime, the new value will be used for checks issued after

# the change.

interval = 200 milliseconds

# The timeout after which schema agreement fails.

# If this is set to 0, schema agreement is skipped and will always fail.

# This option can be changed at runtime, the new value will be used for checks issued after

# the change.

timeout = 10 seconds

# Whether to log a warning if schema agreement fails.

# You might want to change this if you've set the timeout to 0.

# This option can be changed at runtime, the new value will be used for checks issued after

# the change.

warn-on-failure = true

}

}

# The component that coalesces writes on the connections.

# This is exposed mainly to facilitate tuning during development. You shouldn't have to adjust

# this.

coalescer {

class = com.datastax.oss.driver.internal.core.channel.DefaultWriteCoalescer

# How many times the coalescer is allowed to reschedule itself when it did no work.

max-runs-with-no-work = 5

# The reschedule interval.

reschedule-interval = 10 microseconds

}

# The driver maintains a connection pool to each node, according to the distance assigned to it

# by the load balancing policy. If the distance is IGNORED, no connections are maintained.

pool {

local {

# The number of connections in the pool.

#

# This option can be changed at runtime; when the change is detected, all active pools will

# adjust their size.

size = 1

}

remote {

size = 1

}

}

socket {

# 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.

#

# See java.net.StandardSocketOptions.TCP_NODELAY.

tcpNoDelay = true

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

# Netty transport:

# - NIO uses the defaults from java.net.Socket (refer to the javadocs of

# java.net.StandardSocketOptions for each option).

# - Epoll delegates to the underlying file descriptor, which uses the O/S defaults.

# Whether or not to enable TCP keep-alive probes.

#

# See java.net.StandardSocketOptions.SO_KEEPALIVE.

//keepAlive = false

# Whether or not to allow address reuse.

#

# See java.net.StandardSocketOptions.SO_REUSEADDR.

//reuseAddress = true

# 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.

#

# See java.net.StandardSocketOptions.SO_LINGER.

//lingerInterval = 0

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

#

# See java.net.StandardSocketOptions.SO_RCVBUF.

//receiveBufferSize = 65535

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

#

# See java.net.StandardSocketOptions.SO_SNDBUF.

//sendBufferSize = 65535

}

}

request {

# 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.

#

# This option can be changed at runtime, the new value will be used for requests issued after

# the change. It can be overridden in a profile.

#

# 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).

timeout = 2 seconds

# The consistency level.

#

# This option can be changed at runtime, the new value will be used for requests issued after

# the change. It can be overridden in a profile.

consistency = LOCAL_ONE

# 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.

#

# This option can be changed at runtime, the new value will be used for requests issued after

# the change. It can be overridden in a profile.

page-size = 5000

# The serial consistency level.

# The allowed values are SERIAL and LOCAL_SERIAL.

#

# This option can be changed at runtime, the new value will be used for requests issued after

# the change. It can be overridden in a profile.

serial-consistency = SERIAL

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

# keyspace.

# Switching keyspace at runtime is highly discouraged, because it is inherently unsafe (other

# requests expecting the old keyspace might be running concurrently), and may cause statements

# prepared before the change to fail.

# It should only be done in very specific use cases where there is only a single client thread

# executing synchronous queries (such as a cqlsh-like interpreter). In other cases, clients

# should prefix table names in their queries instead.

#

# Note that CASSANDRA-10145 (scheduled for C* 4.0) will introduce a per-request keyspace

# option as a workaround to this issue.

#

# This option can be changed at runtime, it will apply to keyspace switches occurring after the

# change.

warn-if-set-keyspace = true

# The default idempotence of a request, that will be used for all `Request` instances where

# `isIdempotent()` returns null.

#

# This option can be changed at runtime, the new value will be used for requests issued after

# the change. It can be overridden in a profile.

default-idempotence = false

# The generator that assigns a microsecond timestamp to each request.

timestamp-generator {

# The implementation to use. Built-in options are (all from the package

# com.datastax.oss.driver.api.core.time):

# - AtomicTimestampGenerator: timestamps are guaranteed to be unique across all client threads.

# - ThreadLocalTimestampGenerator: timestamps that are guaranteed to be unique within each

# thread only.

# - ServerSideTimestampGenerator: do not generate timestamps, let the server assign them.

class = com.datastax.oss.driver.api.core.time.AtomicTimestampGenerator

# To guarantee that queries are applied on the server in the same order as the client issued

# them, timestamps must be strictly increasing. But this means that, if the driver sends more

# than one query per microsecond, timestamps will drift in the future. While this could happen

# occasionally under high load, it should not be a regular occurrence. Therefore the built-in

# implementations log a warning to detect potential issues.

drift-warning {

# 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.

threshold = 1 second

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

interval = 10 seconds

}

# 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).

# Unless you explicitly want to avoid native calls, there's no reason to change this.

force-java-clock = false

}

retry-policy {

class = com.datastax.oss.driver.api.core.retry.DefaultRetryPolicy

}

speculative-execution-policy {

# Don't schedule any speculative executions

class = com.datastax.oss.driver.api.core.specex.NoSpeculativeExecutionPolicy

# Schedule a fixed number of executions, with a fixed delay

// class = com.datastax.oss.driver.api.core.specex.ConstantSpeculativeExecutionPolicy

# The maximum number of executions (including the initial, non-speculative execution).

# This must be at least one.

// max-executions = 3

# The delay between each execution. 0 is allowed, and will result in all executions being sent

# simultaneously when the request starts.

# Note that sub-millisecond precision is not supported, any excess precision information will

# be dropped; in particular, delays of less than 1 millisecond are equivalent to 0.

# This must be positive or 0.

// delay = 100 milliseconds

}

# If tracing is enabled for a query, this controls how the trace is fetched.

# These options can be changed at runtime, the new values will be used for requests issued after

# the change. They can be overridden in a profile.

trace {

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

attempts = 5

# The interval between each attempt.

interval = 3 milliseconds

# The consistency level to use for trace queries.

# Note that the default replication strategy for the system_traces keyspace is SimpleStrategy

# with RF=2, therefore LOCAL_ONE might not work if the local DC has no replicas for a given

# trace id.

consistency = ONE

}

# A session-wide component that controls the rate at which requests are executed.

#

# Implementations vary, but throttlers generally track a metric that represents the level of

# utilization of the session, and prevent new requests from starting when that metric exceeds a

# threshold. Pending requests may be enqueued and retried later.

#

# From the public API's point of view, this process is mostly transparent: any time that the

# request is throttled is included in the session.execute() or session.executeAsync() call.

# Similarly, the request timeout encompasses throttling: the timeout starts ticking before the

# throttler has started processing the request; a request may time out while it is still in the

# throttler's queue, before the driver has even tried to send it to a node.

#

# The only visible effect is that a request may fail with a RequestThrottlingException, if the

# throttler has determined that it can neither allow the request to proceed now, nor enqueue it;

# this indicates that your session is overloaded.

throttler {

# The following implementations are provided out of the box (all located in the package

# com.datastax.oss.driver.internal.core.session.throttling):

#

# - PassThroughRequestThrottler: does not perform any kind of throttling, all requests are

# allowed to proceed immediately. Required options: none.

#

# - ConcurrencyLimitingRequestThrottler: limits the number of requests that can be executed

# in parallel. Required options: max-concurrent-requests, max-queue-size.

#

# - RateLimitingRequestThrottler: limits the request rate per second. Required options:

# max-requests-per-second, max-queue-size, drain-interval.

class = com.datastax.oss.driver.internal.core.session.throttling.PassThroughRequestThrottler

# The maximum number of requests that can be enqueued when the throttling threshold is

# exceeded. Beyond that size, requests will fail with a RequestThrottlingException.

// max-queue-size = 10000

# The maximum number of requests that are allowed to execute in parallel.

# Only used by ConcurrencyLimitingRequestThrottler.

// max-concurrent-requests = 10000

# The maximum allowed request rate.

# Only used by RateLimitingRequestThrottler.

// max-requests-per-second = 10000

# How often the throttler attempts to dequeue requests. This is the only way for rate-based

# throttling, because the completion of an active request does not necessarily free a "slot"

# for a queued one (the rate might still be too high).

#

# You want to set this high enough that each attempt will process multiple entries in the

# queue, but not delay requests too much. A few milliseconds is probably a happy medium.

#

# Only used by RateLimitingRequestThrottler.

// drain-interval = 10 milliseconds

}

}

prepared-statements {

# Whether `Session.prepare` calls should be sent to all nodes in the cluster.

#

# A request to prepare is handled in two steps:

# 1) send to a single node first (to rule out simple errors like malformed queries).

# 2) if step 1 succeeds, re-send to all other active nodes (i.e. not ignored by the load

# balancing policy).

# This option controls whether step 2 is executed.

#

# The reason why you might want to disable it is to optimize network usage if you have a large

# number of clients preparing the same set of statements at startup. If your load balancing

# policy distributes queries randomly, each client will pick a different host to prepare its

# statements, and on the whole each host has a good chance of having been hit by at least one

# client for each statement.

# On the other hand, if that assumption turns out to be wrong and one host hasn't prepared a

# given statement, it needs to be re-prepared on the fly the first time it gets executed; this

# causes a performance penalty (one extra roundtrip to resend the query to prepare, and another

# to retry the execution).

#

# This option can be changed at runtime, the new value will be used for prepares issued after

# the change. It can be overridden in a profile.

prepare-on-all-nodes = true

# How the driver replicates prepared statements on a node that just came back up or joined the

# cluster.

# These options can be changed at runtime, the new values will be used for prepares issued after

# the change. However they can not be overridden in a profile.

reprepare-on-up {

# 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).

enabled = true

# 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.

check-system-table = false

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

# limit.

max-statements = 0

# The maximum number of concurrent requests when repreparing.

max-parallelism = 100

# The request timeout. This applies both to querying the system.prepared_statements table (if

# relevant), and the prepare requests themselves.

timeout = ${datastax-java-driver.connection.init-query-timeout}

}

}

metadata {

# Topology events are external signals that inform the driver of the state of Cassandra nodes

# (by default, they correspond to gossip events received on the control connection).

# The debouncer helps smoothen out oscillations if conflicting events are sent out in short

# bursts.

# Debouncing may be disabled by setting the window to 0 or max-events to 1 (this is not

# recommended).

topology-event-debouncer {

# 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.

window = 1 second

# 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.

max-events = 20

}

# Options relating to schema metadata (Cluster.getMetadata.getKeyspaces).

# This metadata is exposed by the driver for informational purposes, and is also necessary for

# token-aware routing.

schema {

# Whether schema metadata is enabled.

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

# This option can be changed at runtime, the new value will be used for refreshes issued after

# the change. It can also be overridden programmatically via Cluster.setSchemaMetadataEnabled.

enabled = true

# 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.

# This option can be changed at runtime, the new value will be used for refreshes issued after

# the change.

// refreshed-keyspaces = [ "ks1", "ks2" ]

# The timeout for the requests to the schema tables.

request-timeout = ${datastax-java-driver.request.timeout}

# The page size for the requests to the schema tables.

request-page-size = ${datastax-java-driver.request.page-size}

# Protects against bursts of schema updates (for example when a client issues a sequence of

# DDL queries), by coalescing them into a single update.

# Debouncing may be disabled by setting the window to 0 or max-events to 1 (this is highly

# discouraged for schema refreshes).

debouncer {

# 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.

window = 1 second

# The maximum number of refreshes that can accumulate. If this count is reached, a refresh

# is done immediately and the window is reset.

max-events = 20

}

}

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

# This metadata is exposed by the driver for informational purposes, and is also necessary for

# token-aware routing.

# If this is false, it will remain empty, or to the last known value. Note that its computation

# requires information about the schema; therefore if schema metadata is disabled or filtered to

# a subset of keyspaces, the token map will be incomplete, regardless of the value of this

# property.

# This option can be changed at runtime, the new value will be used for refreshes issued after

# the change.

token-map.enabled = true

}

metrics {

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

session {

enabled = [

# The number of nodes to which the driver has at least one active connection (exposed as a

# Gauge<Integer>).

// connected-nodes,

# The throughput and latency percentiles of CQL requests (exposed as a Timer).

#

# This corresponds to the overall duration of the session.execute() call, including any

# retry.

// cql-requests,

# The number of CQL requests that timed out -- that is, the session.execute() call failed

# with a DriverTimeoutException (exposed as a Counter).

// cql-client-timeouts,

# How long requests are being throttled (exposed as a Timer).

#

# This is the time between the start of the session.execute() call, and the moment when the

# throttler allows the request to proceed.

// throttling.delay,

# The size of the throttling queue (exposed as a Gauge<Integer>).

#

# This is the number of requests that the throttler is currently delaying in order to

# preserve its SLA. This metric only works with the built-in concurrency- and rate-based

# throttlers; in other cases, it will always be 0.

// throttling.queue-size,

# The number of times a request was rejected with a RequestThrottlingException (exposed as a

# Counter)

// throttling.errors,

]

# Extra configuration (for the metrics that need it)

cql-requests {

# The largest latency that we expect to record.

#

# This should be slightly higher than request.timeout (in theory, readings can't be higher

# than the timeout, but there might be a small overhead due to internal scheduling).

#

# This is used to scale internal data structures. If a higher recording is encountered at

# runtime, it is discarded and a warning is logged.

highest-latency = 3 seconds

# 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.

significant-digits = 3

# The interval at which percentile data is refreshed.

#

# The driver records latency data in a "live" histogram, and serves results from a cached

# snapshot. Each time the snapshot gets older than the interval, the two are switched. Note

# that this switch happens upon fetching the metrics, so if you never fetch the recording

# interval might grow higher (that shouldn't be an issue in a production environment because

# you would typically have a metrics reporter that exports to a monitoring tool at a regular

# interval).

#

# In practice, this means that if you set this to 5 minutes, you're looking at data from a

# 5-minute interval in the past, that is at most 5 minutes old. If you fetch the metrics at

# a faster pace, you will observe the same data for 5 minutes until the interval expires.

#

# Note that this does not apply to the total count and rates (those are updated in real

# time).

refresh-interval = 5 minutes

}

throttling.delay {

highest-latency = 3 seconds

significant-digits = 3

refresh-interval = 5 minutes

}

}

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

node {

enabled = [

# The number of connections open to this node for regular requests (exposed as a

# Gauge<Integer>).

#

# This includes the control connection (which uses at most one extra connection to a random

# node in the cluster).

// pool.open-connections,

# The number of stream ids available on the connections to this node (exposed as a

# Gauge<Integer>).

#

# Stream ids are used to multiplex requests on each connection, so this is an indication of

# how many more requests the node could handle concurrently before becoming saturated (note

# that this is a driver-side only consideration, there might be other limitations on the

# server that prevent reaching that theoretical limit).

// pool.available-streams,

# The number of requests currently executing on the connections to this node (exposed as a

# Gauge<Integer>). This includes orphaned streams.

// pool.in-flight,

# The number of "orphaned" stream ids on the connections to this node (exposed as a

# Gauge<Integer>).

#

# See the description of the connection.max-orphan-requests option for more details.

// pool.orphaned-streams,

# The throughput and latency percentiles of individual CQL messages sent to this node as

# part of an overall request (exposed as a Timer).

#

# Note that this does not necessarily correspond to the overall duration of the

# session.execute() call, since the driver might query multiple nodes because of retries and

# speculative executions. Therefore a single "request" (as seen from a client of the driver)

# can be composed of more than one of the "messages" measured by this metric.

#

# Therefore this metric is intended as an insight into the performance of this particular

# node. For statistics on overall request completion, use the session-level cql-requests.

// cql-messages,

# The number of times the driver failed to send a request to this node (exposed as a

# Counter).

#

# In those case we know the request didn't even reach the coordinator, so they are retried

# on the next node automatically (without going through the retry policy).

// errors.request.unsent,

# The number of times a request was aborted before the driver even received a response from

# this node (exposed as a Counter).

#

# This can happen in two cases: if the connection was closed due to an external event (such

# as a network error or heartbeat failure); or if there was an unexpected error while

# decoding the response (this can only be a driver bug).

// errors.request.aborted,

# The number of times this node replied with a WRITE_TIMEOUT error (exposed as a Counter).

#

# Whether this error is rethrown directly to the client, rethrown or ignored is determined

# by the RetryPolicy.

// errors.request.write-timeouts,

# The number of times this node replied with a READ_TIMEOUT error (exposed as a Counter).

#

# Whether this error is rethrown directly to the client, rethrown or ignored is determined

# by the RetryPolicy.

// errors.request.read-timeouts,

# The number of times this node replied with an UNAVAILABLE error (exposed as a Counter).

#

# Whether this error is rethrown directly to the client, rethrown or ignored is determined

# by the RetryPolicy.

// errors.request.unavailables,

# The number of times this node replied with an error that doesn't fall under other errors.*

# metrics (exposed as a Counter).

// errors.request.others,

# The total number of errors on this node that caused the RetryPolicy to trigger a retry

# (exposed as a Counter).

#

# This is a sum of all the other retries.* metrics.

// retries.total,

# The number of errors on this node that caused the RetryPolicy to trigger a retry, broken

# down by error type (exposed as Counters).

// retries.aborted,

// retries.read-timeout,

// retries.write-timeout,

// retries.unavailable,

// retries.other,

# The total number of errors on this node that were ignored by the RetryPolicy (exposed as a

# Counter).

#

# This is a sum of all the other ignores.* metrics.

// ignores.total,

# The number of errors on this node that were ignored by the RetryPolicy, broken down by

# error type (exposed as Counters).

// ignores.aborted,

// ignores.read-timeout,

// ignores.write-timeout,

// ignores.unavailable,

// ignores.other,

# The number of speculative executions triggered by a slow response from this node (exposed

# as a Counter).

// speculative-executions,

# The number of errors encountered while trying to establish a connection to this node

# (exposed as a Counter).

#

# Connection errors are not a fatal issue for the driver, failed connections will be retried

# periodically according to the reconnection policy. You can choose whether or not to log

# those errors at WARN level with the connection.warn-on-init-error option.

#

# Authentication errors are not included in this counter, they are tracked separately in

# errors.connection.auth.

// errors.connection.init,

# The number of authentication errors encountered while trying to establish a connection to

# this node (exposed as a Counter).

# Authentication errors are also logged at WARN level.

// errors.connection.auth,

]

// See cql-requests in the `session` section

cql-messages {

highest-latency = 3 seconds

significant-digits = 3

refresh-interval = 5 minutes

}

}

}

# The address translator to use to convert the addresses sent by Cassandra nodes into ones that

# the driver uses to connect.

# This is only needed if the nodes are not directly reachable from the driver (for example, the

# driver is in a different network region and needs to use a public IP, or it connects through

# a proxy).

address-translator {

# This default implementation always returns the same address unchanged.

class = com.datastax.oss.driver.api.core.addresstranslation.PassThroughAddressTranslator

}

# The SSL engine factory that will initialize an SSL engine for each new connection to a server.

ssl-engine-factory {

# This property is optional; if it is not present, SSL won't be activated.

// class = com.datastax.oss.driver.api.core.ssl.DefaultSslEngineFactory

# Sample configuration for the default SSL factory:

# The cipher suites to enable when creating an SSLEngine for a connection.

# This property is optional. If it is not present, the driver won't explicitly enable cipher

# suites on the engine, which according to the JDK documentations results in "a minimum

# quality of service".

// cipher-suites = [ "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA" ]

}

# Options related to the Netty event loop groups used internally by the driver.

netty {

# The event loop group used for I/O operations (reading and writing to Cassandra nodes).

io-group {

# The number of threads.

# If this is set to 0, the driver will use `Runtime.getRuntime().availableProcessors() * 2`.

size = 0

# 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.

shutdown {quiet-period = 2, timeout = 15, unit = SECONDS}

}

# The event loop group used for admin tasks not related to request I/O (handle cluster events,

# refresh metadata, schedule reconnections, etc.)

admin-group {

size = 2

shutdown {quiet-period = 2, timeout = 15, unit = SECONDS}

}

}

profiles {

# This is where your custom profiles go, for example:

# olap {

# request.timeout = 5 seconds

# }

}

}