-
Notifications
You must be signed in to change notification settings - Fork 987
Client Options
Client options allow controlling behavior for some specific features.
Client options are immutable. Connections inherit the current options at the moment the connection is created. Changes to options will not affect existing connections.
client.setOptions(ClientOptions.builder()
.autoReconnect(false)
.pingBeforeActivateConnection(true)
.build());
Name | Method | Default |
---|---|---|
PING before activating connection |
|
|
Since: 3.1, 4.0 Perform a lightweight Failed The |
||
Auto-Reconnect |
|
|
Since: 3.1, 4.0 Controls auto-reconnect behavior on connections. As soon as a connection gets closed/reset without the intention to close it, the client will try to reconnect, activate the connection and re-issue any queued commands. This flag also has the effect that disconnected connections will refuse commands and cancel these with an exception. |
||
Cancel commands on reconnect failure |
|
|
Since: 3.1, 4.0 This flag is deprecated and should not be used as it can lead to race conditions and protocol offsets. SSL is natively supported by Lettuce and does no longer requires the use of SSL tunnels where protocol traffic can get out of sync. If this flag is |
||
Policy how to reclaim decode buffer memory |
|
|
Since: 6.0 Policy to discard read bytes from the decoding aggregation buffer to reclaim memory. See |
||
Suspend reconnect on protocol failure |
|
|
Since: 3.1, 4.0 If this flag is Reconnection can be activated again, but there is no public API to obtain the |
||
Request queue size |
|
|
Since: 3.4, 4.1 Controls the per-connection request queue size. The command invocation will lead to a |
||
Disconnected behavior |
|
|
Since: 3.4, 4.1 A connection can behave in a disconnected state in various ways. The auto-connect feature allows in particular to retrigger commands that have been queued while a connection is disconnected. The disconnected behavior setting allows fine-grained control over the behavior. Following settings are available:
|
||
Protocol Version |
|
|
Since: 6.0 Configuration of which protocol version (RESP2/RESP3) to use. Leaving this option unconfigured performs a protocol discovery to use the lastest available protocol. |
||
Script Charset |
|
|
Since: 6.0 Charset to use for Luascripts. |
||
Socket Options |
|
|
Since: 4.3 Options to configure low-level socket options for the connections kept to Redis servers. |
||
SSL Options |
|
|
Since: 4.3 Configure SSL options regarding SSL providers (JDK/OpenSSL) and key store/trust store. |
||
Timeout Options |
|
|
Since: 5.1 Options to configure command timeouts applied to timeout commands after dispatching these (active connections, queued while disconnected, batch buffer). By default, the synchronous API times out commands using |
||
Publish Reactive Signals on Scheduler |
|
|
Since: 5.1.4 Use a dedicated |
Cluster client options extend the regular client options by some cluster specifics.
Cluster client options are immutable. Connections inherit the current options at the moment the connection is created. Changes to options will not affect existing connections.
ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
.enablePeriodicRefresh(refreshPeriod(10, TimeUnit.MINUTES))
.enableAllAdaptiveRefreshTriggers()
.build();
client.setOptions(ClusterClientOptions.builder()
.topologyRefreshOptions(topologyRefreshOptions)
.build());
Name | Method | Default |
---|---|---|
Periodic cluster topology refresh |
|
|
Since: 3.1, 4.0 Enables or disables periodic cluster topology refresh. The refresh is handled in the background. Partitions, the view on the Redis cluster topology, are valid for a whole The refresh job is regularly executed, the period between the runs can be set with |
||
Cluster topology refresh period |
|
|
Since: 3.1, 4.0 Set the period between the refresh job runs. The effective interval cannot be changed once the refresh job is active. Changes to the value will be ignored. |
||
Adaptive cluster topology refresh |
|
|
Since: 4.2 Enables selectively adaptive topology refresh triggers. Adaptive refresh triggers initiate topology view updates based on events happened during Redis Cluster operations. Adaptive triggers lead to an immediate topology refresh. These refreshes are rate-limited using a timeout since events can happen on a large scale. Adaptive refresh triggers are disabled by default. Following triggers can be enabled:
|
||
Adaptive refresh triggers timeout |
|
|
Since: 4.2 Set the timeout between the adaptive refresh job runs. Multiple triggers within the timeout will be ignored, only the first enabled trigger leads to a topology refresh. The effective period cannot be changed once the refresh job is active. Changes to the value will be ignored. |
||
Reconnect attempts (Adaptive topology refresh trigger) |
|
|
Since: 4.2 Set the threshold for the |
||
Dynamic topology refresh sources |
|
|
Since: 4.2 Discover cluster nodes from the topology and use only the discovered nodes as the source for the cluster topology. Using dynamic refresh will query all discovered nodes for the cluster topology details. If set to Note that enabling dynamic topology refresh sources uses node addresses reported by Redis |
||
Close stale connections |
|
|
Since: 3.3, 4.1 Stale connections are existing connections to nodes which are no longer part of the Redis Cluster. If this flag is set to |
||
Limitation of cluster redirects |
|
|
Since: 3.1, 4.0 When the assignment of a slot-hash is moved in a Redis Cluster and a client requests a key that is located on the moved slot-hash, the Cluster node responds with a |
||
Filter nodes from Topology |
|
|
Since: 6.1.6 When providing a |
||
Validate cluster node membership |
|
|
Since: 3.3, 4.0 Validate the cluster node membership before allowing connections to that node. The current implementation performs redirects using There are some scenarios, where the strict validation is an obstruction:
Connecting to non-cluster members to reconfigure those while using the RedisClusterClient connection. |
Lettuce documentation was moved to https://redis.github.io/lettuce/overview/
Intro
Getting started
- Getting started
- Redis URI and connection details
- Basic usage
- Asynchronous API
- Reactive API
- Publish/Subscribe
- Transactions/Multi
- Scripting and Functions
- Redis Command Interfaces
- FAQ
HA and Sharding
Advanced usage
- Configuring Client resources
- Client Options
- Dynamic Command Interfaces
- SSL Connections
- Native Transports
- Unix Domain Sockets
- Streaming API
- Events
- Command Latency Metrics
- Tracing
- Stateful Connections
- Pipelining/Flushing
- Connection Pooling
- Graal Native Image
- Custom commands
Integration and Extension
Internals