Default settings:

• contact point is "localhost" port 9042
• load-balancing policy is random
• binary protocol version is 3
• connection idle timeout is 60s
• the connection pool uses 4 stripes to mitigate thread contention
• connections use a connect timeout of 5s, a send timeout of 3s and a receive timeout of 10s
• 128 streams per connection are used
• 16k receive buffer size
• no compression is applied to frame bodies
• no default keyspace is used.
• no retries are done
• lazy prepare strategy

Add an additional host to the contact list.

Set the compression to use for frame body compression.

Set the connect timeout of a connection.

Set the initial contact points (hosts) from which node discovery will start.

Set the connection idle timeout. Connections in a pool will be closed if not in use for longer than this timeout.

Set the default keyspace to use. Every new connection will be initialised to use this keyspace.

Maximum connections per pool stripe.

Set the maximum number of streams per connection. In version 2 of the binary protocol at most 128 streams can be used. Version 3 supports up to 32768 streams.

When receiving a response times out, we can no longer use the stream of the connection that was used to make the request as it is uncertain if a response will arrive later. Thus the bandwith of a connection will be decreased. This settings defines a threshold after which we close the connection to get a new one with all streams available.

Set the load-balancing policy.

Set the number of pool stripes to use. A good setting is equal to the number of CPU cores this codes is running on.

Set the portnumber to use to connect on every node of the cluster.

Strategy for the execution of PrepQuerys.

Set strategy to use for preparing statements.

Set the binary protocol version to use.

Set the receive timeout of a connection. Requests exceeding the receive timeout will fail with a Timeout exception.

Set the send timeout of a connection. Request exceeding the send will cause the connection to be closed and fail with ConnectionClosed exception.

Set default retry settings to use.

Set maximum receive buffer size.

The actual buffer size used will be the minimum of the CQL response size and the value set here.

Set a fully configured SSL context.

This will make client server queries use TLS.

Set the supported authentication mechanisms.

When a Cassandra server requests authentication on a connection, it specifies the requested AuthMechanism. The client Authenticator is chosen based that name. If no authenticator with a matching name is configured, an AuthenticationError is thrown.

A client authentication handler.

The fields of an Authenticator must implement the client-side of an (SASL) authentication mechanism as follows:

• When a Cassandra server requests authentication on a new connection, authOnRequest is called with the AuthContext of the connection.
• If additional challenges are posed by the server, authOnChallenge is called, if available, otherwise an AuthenticationError is thrown, i.e. every challenge must be answered.
• Upon successful authentication authOnSuccess is called.

The existential type s is chosen by an implementation and can be used to thread arbitrary state through the sequence of callback invocations during an authentication exchange.

See also: RFC4422 Authentication

Context information given to Authenticators when the server requests authentication on a connection. See authOnRequest.

The (unique) name of a SASL authentication mechanism.

In the case of Cassandra, this is currently always the fully-qualified Java class name of the configured server-side IAuthenticator implementation.

A password authentication handler for use with Cassandra's PasswordAuthenticator.

See: Configuring Authentication

Never retry.

Forever retry immediately.

Limit number of retries.

When retrying a (batch-) query, change consistency to the given value.

Wait a constant time between retries.

Delay retries with exponential backoff.

Delay retries using Fibonacci sequence as backoff.

On retry adjust the send timeout.

On retry adjust the response timeout.

A policy defines a load-balancing strategy and generally handles host visibility.

Return hosts in random order.

Iterate over hosts one by one.

Host representation.

This event will be passed to a Policy to inform it about cluster changes.

The IP address and port number of this host.

The data centre name (may be an empty string).

The rack name (may be an empty string).

The Client monad.

A simple reader monad around some internal state. Prior to executing this monad via runClient, its state must be initialised through init and after finishing operation it should be terminated with shutdown.

To lift Client actions into another monad, see MonadClient.

Monads in which Client actions may be embedded.

Opaque client state/environment.

Initialise client state with the given Settings using the provided Logger for all it's logging output.

Execute the client monad.

Terminate client state, i.e. end all running background checks and shutdown all connection pools. Once this is entered, the client will eventually be shut down, though an asynchronous exception can interrupt the wait for that to occur.

Type tag for read queries, i.e. 'QueryString R a b'.

Type tag for write queries, i.e. 'QueryString W a b'.

Type tag for schema queries, i.e. 'QueryString S a b'.

Query parameters.

Construct default QueryParams for the given consistency and bound values. In particular, no page size, paging state or serial consistency will be set.

Consistency level.

See: Consistency

Consistency level for the serial phase of conditional updates (aka "lightweight transactions").

See: SerialConsistency

Identity functor and monad. (a non-strict monad)

Since: base-4.8.0.0

Run a CQL read-only query returning a list of results.

Run a CQL read-only query returning a single result.

Run a CQL write-only query (e.g. insert/update/delete), returning no result.

/Note: If the write operation is conditional, i.e. is in fact a "lightweight transaction" returning a result, trans must be used instead./

Run a CQL schema query, returning SchemaChange information, if any.

Representation of a prepared QueryString. A prepared query is executed in two stages:

1. The query string is sent to a server without parameters for preparation. The server responds with a QueryId.
2. The prepared query is executed by sending the QueryId and parameters to the server.

Thereby step 1 is only performed when the query has not yet been prepared with the host (coordinator) used for query execution. Thus, prepared queries enhance performance by avoiding the repeated sending and parsing of query strings.

Query preparation is handled transparently by the client. See setPrepareStrategy.

Note

Prepared statements are fully supported but rely on some assumptions beyond the scope of the CQL binary protocol specification (spec):

1. The spec scopes the QueryId to the node the query has been prepared with. The spec does not state anything about the format of the QueryId. However the official Java driver assumes that any given QueryString yields the same QueryId on every node. This client make the same assumption.
2. In case a node does not know a given QueryId an Unprepared error is returned. We assume that it is always safe to transparently re-prepare the corresponding QueryString and to re-execute the original request against the same node.

Besides these assumptions there is also a potential tradeoff in regards to eager vs. lazy query preparation. We understand eager to mean preparation against all current nodes of a cluster and lazy to mean preparation against a single node on demand, i.e. upon receiving an Unprepared error response. Which strategy to choose depends on the scope of query reuse and the size of the cluster. The global default can be changed through the Settings module as well as locally using withPrepareStrategy.

Return value of paginate. Contains the actual result values as well as an indication of whether there is more data available and the actual action to fetch the next page.

A page with an empty result list.

Run a CQL read-only query against a Cassandra node.

This function is like query, but limits the result size to 10000 (default) unless there is an explicit size restriction given in QueryParams. The returned Page can be used to continue the query.

Please note that -- as of Cassandra 2.1.0 -- if your requested page size is equal to the result size, hasMore might be true and a subsequent nextPage will return an empty list in result.

A row is a vector of Values.

Convert a row element.

Run a CQL conditional write query (e.g. insert/update/delete) as a "lightweight transaction", returning the result Rows describing the outcome.

Batch construction monad.

Add a query to this batch.

Add a prepared query to this batch.

Set the type of this batch.

Set Batch consistency level.

Set Batch serial consistency.

Run a batch query against a Cassandra node.

Use given RetrySettings during execution of some client action.

Execute a client action once, without retries, i.e.

once action = retry noRetry action.

Primarily for use in applications where global RetrySettings are configured and need to be selectively disabled for individual queries.

A type which can be run as a query.

Send a Request to the server and return a Response.

This function will first ask the clients load-balancing Policy for some host and use its connection pool to acquire a connection for request transmission.

If all available hosts are busy (i.e. their connection pools are fully utilised), the function will block until a connection becomes available or the maximum wait-queue length has been reached.

The request is retried according to the configured RetrySettings.