# Defines the name of the Cassandra cluster. Technically this name does not correlate
# with the name configured in the real Cassandra cluster, but it's rather used to distinguish
# exposed JMX metrics when multiple Cluster instances live in the same JVM
com.openexchange.nosql.cassandra.clusterName=OX

# Defines the Cassandra seed node(s) as a comma separated list
com.openexchange.nosql.cassandra.clusterContactPoi nts=127.0.0.1

# Defines the port on which the Cassandra server is running
# Defaults to 9042
com.openexchange.nosql.cassandra.port=9042

# Defines load balancing policy to use for the cluster. There are three load balancing policies
# to choose from: RoundRobin, DCAwareRoundRobin and DCTokenAwareRoundRobin
#
# RoundRobin
# ----------
# A Round-robin load balancing policy.
#
# This policy queries nodes in a round-robin fashion. For a given query,
# if an host fail, the next one (following the round-robin order) is
# tried, until all hosts have been tried.
#
# This policy is not datacenter aware and will include every known
# Cassandra host in its round robin algorithm. If you use multiple
# datacenter this will be inefficient and you will want to use the
# DCAwareRoundRobin load balancing policy instead.
#
# DCAwareRoundRobin
# -----------------
# A data-center aware Round-robin load balancing policy.
#
# This policy provides round-robin queries over the node of the local
# data center. It also includes in the query plans returned a configurable
# number of hosts in the remote data centers, but those are always tried
# after the local nodes. In other words, this policy guarantees that no
# host in a remote data center will be queried unless no host in the local
# data center can be reached.
#
# If used with a single data center, this policy is equivalent to the
# RoundRobin, but its DC awareness incurs a slight overhead
# so the latter should be preferred to this policy in that case.
#
# DCTokenAwareRoundRobin
# ----------------------
# Same as the DCAwareRoundRobin load balancing policy but with
# added token awareness.
#
# Defaults to RoundRobin
com.openexchange.nosql.cassandra.loadBalancingPoli cy=RoundRobin

# A policy that defines a default behaviour to adopt when a request fails. There are three
# retry policies to choose from: defaultRetryPolicy, downgradingConsistencyRetryPolicy
# and fallthroughRetryPolicy
#
# defaultRetryPolicy
# ------------------
# This policy retries queries in only two cases:
# - On a read timeout, if enough replicas replied but data was not retrieved.
# - On a write timeout, if we timeout while writing the distributed log used by batch statements.
#
# This retry policy is conservative in that it will never retry with a
# different consistency level than the one of the initial operation.
#
# In some cases, it may be convenient to use a more aggressive retry policy
# like downgradingConsistencyRetryPolicy.
#
# downgradingConsistencyRetryPolicy
# ---------------------------------
# A retry policy that sometimes retries with a lower consistency level than
# the one initially requested.
#
# BEWARE: this policy may retry queries using a lower consistency
# level than the one initially requested. By doing so, it may break
# consistency guarantees. In other words, if you use this retry policy,
# there are cases where a read at QUORUM may NOT see a preceding write
# at QUORUM. Do not use this policy unless you have understood the cases
# where this can happen and are ok with that. It is also highly recommended
# to always enable the logRetryPolicy to log the occurrences of such consistency
# breaks.
#
# fallthroughRetryPolicy
# ----------------------
# A retry policy that never retries (nor ignores).
#
# Defaults to defaultRetryPolicy
com.openexchange.nosql.cassandra.retryPolicy=defau ltRetryPolicy

# Logs the retry decision of the policy
#
# Defaults to false
com.openexchange.nosql.cassandra.logRetryPolicy=fa lse

# Enables the query logger which logs all executed statements
#
# Defatuls to false
com.openexchange.nosql.cassandra.enableQueryLogger =false

# Defines the latency threshold in milliseconds beyond which queries are considered 'slow'
# and logged as such by the Cassandra service. Used in conjunction with the 'enableQueryLogger'
# property
# Default: 5000
com.openexchange.nosql.cassandra.queryLatencyThres hold=5000

# Defines the amount of time (in seconds) for connection keepalive in the form of a heartbeat.
# When a connection has been idle for the given amount of time, the Cassandra service will
# simulate activity by writing a dummy request to it (by sending an OPTIONS message).
#
# To disable heartbeat, set the interval to 0.
#
# Defaults to 30 seconds
com.openexchange.nosql.cassandra.poolingHeartbeat= 30

# The Cassandra service's connection pools have a variable size, which gets adjusted automatically
# depending on the current load. There will always be at least a minimum number of connections, and
# at most a maximum number. These values can be configured independently by host distance (the distance
# is determined by your LoadBalancingPolicy, and will generally indicate whether a host is in the same
# datacenter or not).
#
# Defaults to minimum 4 and maximum 10 for local nodes (i.e. in the same datacenter) and minimum 2 and
# maximum 4 for remote nodes
com.openexchange.nosql.cassandra.minimumLocalConne ctionsPerNode=4
com.openexchange.nosql.cassandra.maximumLocalConne ctionsPerNode=10
com.openexchange.nosql.cassandra.minimumRemoteConn ectionsPerNode=2
com.openexchange.nosql.cassandra.maximumRemoteConn ectionsPerNode=4

# When activity goes down, the driver will trash connections if the maximum number of requests
# in a 10 second time period can be satisfied by less than the number of connections opened. Trashed
# connections are kept open but do not accept new requests. After the given timeout, trashed connections
# are closed and removed. If during that idle period activity increases again, those connections will be
# resurrected back into the active pool and reused.
#
# Defaults to 120 seconds
com.openexchange.nosql.cassandra.idleConnectionTra shTimeout=120

# Defines the throttling of concurrent requests per connection on local (on the same datacenter)
# and remote nodes (on a different datacenter).
#
# For Cassandra clusters that use a protocol v2 and below, there is no reason to throttle.
# It should be set to 128 (the max)
#
# For Cassandra clusters that use a protocol v3 and up, it is set by default to 1024 for LOCAL hosts,
# and to 256 for REMOTE hosts. These low defaults were chosen so that the default configuration
# for protocol v2 and v3 allow the same total number of simultaneous requests (to avoid bad surprises
# when clients migrate from v2 to v3). This threshold can be raised, or even set it to the max which is
# 32768 for LOCAL nodes and 2000 for REMOTE nodes
#
# Note that that high values will give clients more bandwidth and therefore put more pressure on
# the cluster. This might require some tuning, especially with many clients.
com.openexchange.nosql.cassandra.maximumRequestsPe rLocalConnection=1024
com.openexchange.nosql.cassandra.maximumRequestsPe rRemoteConnection=256

# When the CassandraService tries to send a request to a host, it will first try to acquire
# a connection from this host's pool. If the pool is busy (i.e. all connections are already handling
# their maximum number of in flight requests), the acquisition attempt gets enqueued until a
# connection becomes available again.
#
# If the queue has already reached its limit, further attempts to acquire a connection will be
# rejected immediately: the CassandraService will move on and try to acquire a connection from
# the next host's pool. The limit can be set to 0 to disable queueing entirely.
#
# If all hosts are busy with a full queue, the request will fail with a NoHostAvailableException.
com.openexchange.nosql.cassandra.acquistionQueueMa xSize=256