Cassandra CQL resource adaptor configuration
The Cassandra CQL resource adaptor has configuration properties related to:
-
The Cassandra database to connect to — contact points and keyspace
-
Configuration options of the Cassandra cluster — protocol version, port, query consistency level and so on
-
Cassandra database authentication — authentication options for connecting and re-connecting to the database
-
Connecting to the Cassandra database — policies for connecting and re-connecting to the database
-
Socket options — socket options passed to the DataStax driver
-
Load balancing options — a subset of the available load balancing options supported by the DataStax driver
-
Cache of prepared statements — cache size -and entry expiry- configuration (entry expiry is now obsolete)
-
Processing asynchronous responses — threads used for processing asynchronous responses and submitting events to the SLEE
-
Optional switches related to debugging — options that may be useful for debugging
The Cassandra database to connect to
These configuration options define the initial set of hosts the resource adaptor entity should connect to and the keyspace it should use. There is one keyspace per resource adaptor entity. If your application requires several keyspaces, then you must create one resource adaptor entity for each keyspace. These properties may be actively changed (i.e whilst the ra entity is active).
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Comma separated list of hostname/ip addresses of cassandra nodes used to discover the cluster topology. The default value is 'localhost' |
|
|
The keyspace this RA entity should 'connect' to. There is no default, so this property must be defined. |
Contact points are addresses of Cassandra nodes that the resource adaptor uses to discover the cluster topology. Only one contact point is required (the resource adaptor will retrieve the address of the other nodes automatically). It is recommended to use more than one contact point, because if that single contact point is unavailable, the resource adaptor cannot connect to the cluster. |
Configuration options related to the Cassandra cluster
These configuration options define general properties of the connection made to the Cassandra cluster. They may be actively changed (i.e whilst the ra entity is active) and will have an impact on the next time the resource adaptor needs to re-connect to the cassandra cluster.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
The binary protocol version to use. Possible values are: |
|
|
|
The compression method to use with the binary protocol. Possible values are:
|
|
|
|
If SSL should be used (using jdk built-in engine). |
|
|
|
If SSL should be used (defer to the Netty layer). |
|
|
|
The port to connect to the cassandra database |
|
|
|
The default query consistency level. |
|
|
|
The default serial consistency level for conditional updates. The default value is |
|
|
|
The default fetch size (the number of rows) to use for SELECT queries. Allowable values are |
|
|
|
The default timeout (in milliseconds) for synchronous queries if none is supplied. Allowable values are |
|
|
|
The timeout (in milliseconds) for the preparation of queries. Allowable values are |
The configuration options |
Possible consistency levels (from Apache Cassandra™ 2.0 — Configuring data consistency) are:
For more details, refer to Cassandra documentation: |
Cassandra database authentication
These properties determine how the Cassandra CQL resource adaptor authenticates with the Cassandra cluster. These properties may be actively changed (i.e whilst the ra entity is active) and will have an impact on the next time the resource adaptor needs to re-connect to the Cassandra cluster.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Username for Cassandra database authentication |
|
|
|
Password for Cassandra database authentication |
If |
Connecting to the Cassandra database
These properties dictate how the Cassandra CQL resource adaptor directs the DataStax driver to connect to the Cassandra cluster. These properties may be actively changed (i.e whilst the ra entity is active) and will have an impact on the next time the resource adaptor needs to re-connect to the cassandra cluster.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
The two policies available for connection/re-connection (
|
|
|
|
How long (s) between attempts to connect to the Cassandra DB (constant). Acceptable values are 5s to 60s. |
|
|
|
The first delay (s) before attempting to connect to the Cassandra DB (exponential). Acceptable values are 1s to 24s. |
|
|
|
Subsequent delay (s) = 2 x previous delay, capped by max delay (s) (exponential). Acceptable values are 16s to 128s. |
The |
Socket options
These properties correspond to socket options of the DataStax driver.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
How long (ms) to establish a new connection to a Cassandra node before giving up. |
|
|
|
How long (ms) for a given Cassandra node to answer a query. |
|
|
|
True/False/not-set. Whether to enable TCP keepalive. The default, (not-set), means the value used is the default from the underlying Netty transport. |
|
|
|
True/False/not-set. Whether reuse-address is enabled. The default, (not-set), means the value used is the default from the underlying Netty transport. |
|
|
|
The linger-on-close timeout. The default, (-1 == not set), means the value used is the default from the underlying Netty transport. |
|
|
|
Whether to disable Nagle’s algorithm. |
|
|
|
Sets a hint to the size of the underlying buffers for incoming network I/O. The default, (-1 == not set), means the value used is the default from the underlying Netty transport. |
|
|
|
Sets a hint to the size of the underlying buffers for outgoing network I/O. The default, (-1 == not set), means the value used is the default from the underlying Netty transport. |
Setting 'socket.solinger' to 0 disables SO_Linger and is not recommended |
Load balancing options
These properties correspond to a subset of all available load balancing options supported by the DataStax driver.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Select the load-balancing approach to use. Allowed values include: round-robin, dc-aware-round-robin, latency-aware-round-robin, latency-aware-dc-aware-round-robin. A value of use-default uses the driver default. |
|
|
|
How much worse the average latency of a node must be compared to the fastest performing node for it to be penalized. Must be greater than 1.0. A value of 0 means use the driver default. |
|
|
|
Dictates the weight of a latency measurement to previous measurements in average latency. The value must be greater than 0. A value of 0 means use the driver default. |
The following recipes are supported are:
A value of 'use-default' means the DataStax driver default load balancing configuration will be used. The latency-aware load balancing policy collect latencies of the queries to each Cassandra node and maintain a per-node average latency score. The nodes that are slower than the best performing node by more than a configurable threshold will be moved to the end of the query plan (that is, they will only be tried if all other nodes failed). The latency-aware configuration properties include:
|
Cache of prepared statements
The resource adaptor manages a cache of prepared statements, implemented as a LoadingCache<String, PreparedCassandraStatement>
from the Guava library
(guava-libraries — CachesExplained).
See section Preparing statements for more information on preparing statements using the Cassandra CQL resource adaptor API. |
The cache is cleared when the resource adaptor entity is deactivated. The size of the cache, -and the cache entry expiry behaviour- is controlled by the
statementCache.maxSize
and -statementCache.expireAfterAccessT
- properties. These properties may be actively changed (i.e whilst the ra entity is active). Entries in the cache are preserved when properties of the cache are changed.
The configuration option |
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Maximum number of entries in the prepared statement cache |
|
|
|
Obsolete. -Time (s) after which a statement is removed from the cache since it was last used- |
Processing asynchronous responses
The resource adaptor receives asynchronous responses from the DataStax driver and delivers them as events into the Rhino TAS.
This function is implemented using a standard java ThreadPoolExecutor
. The ThreadPoolExecutor
encapsulates a thread pool and a task queue.
The following properties define the configuration of this ThreadPoolExecutor
and should be set to suit the expected rate of asynchrounous responses.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Number of threads available at all times |
|
|
|
Maximum number of threads |
|
|
|
How long (s) to keep non-core threads if they are idle |
|
|
|
The maximum results to queue waiting for a result executor thread |
|
|
|
If the RA guard timer should be used for asynchronous queries |
|
|
|
Milliseconds between scheduler ticks |
|
|
|
Common timer interval in milliseconds |
|
|
|
Maximum timer interval in milliseconds |
These properties may be actively changed (i.e whilst the ra entity is active).
Optional switches for debugging
The resource adaptor will request additional notifications from the Rhino TAS when CassandraSession
activities end if the debug.activity.requestendedcallback
is true
.
The resource adaptor will set the enableTracing
flag on all queries that take a Statement
arg if the debug.activity.tracingenabled
is true
.
This behaviour is not required for normal operation of the resource adaptor, but may be useful during application testing scenarios. These properties can be actively changed (i.e whilst the ra entity is active).
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Should the RA request activity ended notification from the slee |
|
|
|
Should the RA call enableTracing on all Cassandra Statements. |