ClusterConfig(nodeConfigs: (NodeAddress) ⇒ NodeConfig = _ => NodeConfig(), monitoringConnectionConfigs: (NodeAddress) ⇒ ConnectionConfig = _ => ConnectionConfig(), autoRefreshInterval: FiniteDuration = 5.seconds, minRefreshInterval: FiniteDuration = 1.seconds, nodesToQueryForState: (Int) ⇒ Int = _ min 5, redirectionStrategy: RetryStrategy = RetryStrategy.times(3), tryagainStrategy: RetryStrategy = ..., nodeClientCloseDelay: FiniteDuration = 1.seconds, fallbackToSingleNode: Boolean = false) extends Product with Serializable
Configuration of a RedisClusterClient
function that returns NodeConfig given the address of the node.
function that returns ConnectionConfig for a monitoring connection used to monitor node with given address. The cluster client keeps single monitoring connection for every cluster master. Monitoring connections are used to refresh Redis Cluster state (current masters and slot mapping).
interval between routine cluster state refresh operations
minimal interval between consecutive cluster state refresh operations. Normally, cluster state is not refreshed more frequently than specified by
autoRefreshIntervalbut additional refresh operations may be forced when cluster redirections are observed.
minRefreshIntervalprevents too many refresh operations from being executed in such situations.
function that determines how many randomly selected masters should be queried for cluster state during routine state refresh operation. The function takes current number of known masters as its argument.
RetryStrategy that controls Redis Cluster redirection handling (
RetryStrategy that controls retrying commands which failed with
TRYAGAINerror which may be returned for multikey commands during cluster slot migration.
Delay after which RedisNodeClient is closed when it's master leaves cluster state (goes down or becomes a slave). Note that the node client is NOT operational during that delay. Trying to execute commands on it will result in NodeRemovedException
if RedisClusterClient has exactly one seed address configured and it points to a non-clustered Redis node then cluster client will not fail initialization but internally create a RedisNodeClient for that node and forward all operations to it.
ConnectionConfig(initCommands: RedisBatch[Any] = RedisBatch.unit, actorName: commons.OptArg[String] = OptArg.Empty, localAddress: commons.OptArg[InetSocketAddress] = OptArg.Empty, socketOptions: List[SocketOption] = Nil, connectTimeout: commons.OptArg[FiniteDuration] = OptArg.Empty, maxWriteSizeHint: commons.OptArg[Int] = 50000, reconnectionStrategy: RetryStrategy = ..., debugListener: DebugListener = DevNullListener) extends Product with Serializable
Configuration options for a single Redis connection.
commands always sent upon establishing a Redis connection (and every time it's reconnected). The most common reason to configure
initCommandsis to specify authentication password used by every connection (
AUTHcommand), but it's also useful for commands like
SELECT, etc. Note that these are all commands that can't be executed directly by RedisNodeClient or RedisClusterClient.
name of the actor representing the connection
local bind address for the connection
socket options for the connection
timeout for establishing connection
hint for maximum number of bytes sent in a single network write message (the actual number of bytes sent may be slightly larger)
a RetryStrategy used to determine what delay should be used when reconnecting a failed connection. NOTE:
reconnectionStrategyis ignored by
listener for traffic going through this connection. Only for debugging and testing purposes
ExecutionConfig(responseTimeout: Timeout = 10.seconds, decodeOn: commons.ExecutionContext = RunNowEC) extends Product with Serializable
Redis server response timeout. If executing a batch involves retries (e.g. because of cluster redirections) then timeout is applied independently on every retry.
execution context on which Redis response to a batch will be decoded. Normally this is happening on one of the connection actor threads. This is ok for simple Redis commands but may introduce performance bottleneck for large batches with more heavy decoding. In such case it may be beneficial to delegate that work to some external executor.
NodeConfig(poolSize: Int = 1, maxBlockingPoolSize: Int = 4096, maxBlockingIdleTime: Duration = 1.minute, blockingCleanupInterval: FiniteDuration = 1.second, initOp: RedisOp[Any] = RedisOp.unit, initTimeout: Timeout = Timeout(10.seconds), connectionConfigs: (Int) ⇒ ConnectionConfig = _ => ConnectionConfig(), blockingConnectionConfigs: (Int) ⇒ ConnectionConfig = _ => ConnectionConfig()) extends Product with Serializable
Number of connections used by node client. Commands are distributed between connections using a round-robin scenario. Number of connections in the pool is constant and cannot be changed. Due to single-threaded nature of Redis, the number of concurrent connections should be kept low for best performance. The only situation where the number of connections should be increased is when using
EXECtransactions with optimistic locking.
Maximum number of connections used by node client in order to handle blocking Redis commands, e.g.
BLPOP. Blocking commands may not be pipelined with other, independent commands because these other commands may be delayed by the blocking command. Therefore they require their own, dynamically resizable connection pool. Maximum size of that pool is the limit of possible concurrent blocking commands that can be executed at the same time.
Maximum amount of time a blocking connection may be idle before being closed and removed from the pool.
Time interval between periodic blocking connection cleanup events, with respect to maxBlockingIdleTime.
A RedisOp executed by this client upon initialization. This may be useful for things like script loading, especially when using cluster client which may create and close node clients dynamically as reactions on cluster state changes.
Timeout used by initialization operation (
A function that returns ConnectionConfig for a connection given its id. Connection ID is its index in the connection pool, i.e. an int ranging from 0 to
Same as connectionConfigs but for connections used for handling blocking commands.
RetryStrategy extends AnyRef
RetryStrategyis conceptually a lazy sequence of delays, possibly infinite.