Releases · redis/lettuce

06 Jun 14:29

mp911de

4.2.0.Final

fb1d3e1

4.2.0.Final

That's the zero behind 4.2? Well, that's to not break OSGi support. Now let's talk about the more interesting things. Lettuce 4.2.0 is a major release and completes development of several notable enhancements.

This release comes with SSL support, Publish/Subscribe and adaptive topology refreshing for Redis Cluster. It features a major refactoring of the command handling and several improvements for Cloud-based Redis services and improvements to the Master/Slave API.

The usage of Guava was reduced for the most parts. Only the LoadingCache, InetAddresses and HostAndPort components are still in use. A future lettuce 5.0 version will eliminate the use of Guava completely.

Important note for users of connection-pooling and latency tracking

Dependencies were streamlined with this release. Apache's commons-pool2 and latencyutils are now optional dependencies. If you use connection-pooling or latency tracking, please include these dependencies explicitly otherwise these features will be disabled.

Lettuce 4.2.0 was verified with several Cloud-based Redis services. It works with different AWS ElastiCache usage patterns and is known to work with the Azure Redis Cluster service supporting SSL and authentication (see below).

lettuce 4.2.0 is fully binary compatible with the last release and can be used as a drop-in replacement for 4.1.x. This update is strongly recommended for lettuce 4.x users as it fixes some critical connection synchronization bugs.

Thanks to all contributors that made lettuce 4.2.0 possible.

lettuce 4.2.0 requires Java 8 and cannot be used with Java 6 or 7.

Redis Cluster Publish/Subscribe

Redis Cluster provides Publish/Subscribe features to broadcast messages across the cluster.
Using the standalone client allows using Publish/Subscribe with Redis Cluster but comes with the limitation of high-availability/failover.

If a node goes down, the connection is lost until the node is available again. lettuce addresses this issue with Redis Cluster Publish/Subscribe and provides a failover mechanism.

Publish/Subscribe messages and subscriptions are operated on the default cluster connection. The default connection is established with the node with the least client connections to achieve a homogeneous connection distribution. It also uses the cluster topology to failover if the currently connected node is down.

Publishing a message using the regular cluster connection is still possible (since 4.0). The regular cluster connection calculates a slot-hash from the channel (which is the key in this case). Publishing always connects to the master node which is responsible for the slot although PUBLISH is not affected by the keyspace/slot-hash rule.

Redis Cluster and SSL

Redis introduces an option to announce a specific IP address/port using cluster-announce-ip and cluster-announce-port. This is useful for Docker and NAT'ed setups. Furthermore, you can "hide" your Redis Cluster nodes behind any other proxy like stunnel. A Redis Cluster node will announce the specified port/IP which can map to stunnel, and you get an SSL-protected Redis Cluster. Please note that cluster-announce-ip is not part of Redis 3.2 but will be released in future versions.

Redis Cluster SSL works pretty much the same as Redis Standalone with SSL. You can configure SSL and other SSL/TLS options using RedisURI.

RedisURI redisURI = RedisURI.Builder.redis(host(), 7443)
                                .withSsl(true)
                                .withVerifyPeer(false)
                                .build();

RedisClusterClient redisClusterClient = RedisClusterClient.create(redisURI);
StatefulRedisClusterConnection<String, String> connection = redisClusterClient.connect();

You should disable the verifyPeer option if the SSL endpoints cannot provide a valid certificate. When creating a RedisClusterClient using RedisClusterClientFactoryBean the verifyPeer option is disabled by default.

Lettuce was successfully tested with Azure Redis with SSL and authentication.

Redis Cluster Topology Discovery and Refreshing

The lettuce Redis Cluster Client allows regular topology updates. lettuce 4.2.0 improves the existing topology updates with adaptive refreshing and dynamic/static topology discovery.

Adaptive refresh initiates topology view updates based on events happened during Redis Cluster operations. Adaptive triggers lead to an immediate topology refresh. Adaptive updates are rate-limited using a timeout since events can happen on a large scale. Adaptive refresh triggers are disabled by default and
can be enabled selectively:

MOVED_REDIRECT
ASK_REDIRECT
PERSISTENT_RECONNECTS

Dynamic/static topology discovery sources are the second change to topology refresh. lettuce uses by default dynamic discovery. Dynamic discovery retrieves the initial topology from the seed nodes and determines additional nodes to request their topology view. That is to reduce split-brain views by choosing the view which is shared by the majority of cluster nodes.

Dynamic topology discovery also provides latency data and client count for each node in the cluster. These details are useful for calculating the nearest node or the least used node.

Dynamic topology discovery can get expensive when running large Redis Clusters as all nodes from the topology are queried for their view. Static topology refresh sources limit the nodes to the initial seed node set. Limiting nodes is friendly to large clusters but it will provide latency and client count only for the seed nodes.

Redis Modules

Redis module support is a very young feature. lettuce provides a custom command API to dispatch own commands. StatefulConnection already allows sending of commands but requires wrapping of commands into the appropriate synchronization wrapper (Future, Reactive, Fire+Forget).

lettuce provides with 4.2.0 dispatch(…) methods on each API type to provide a simpler interface.

RedisCodec<String, String> codec = new Utf8StringCodec();

String response = redis.dispatch(CommandType.SET,
        new StatusOutput<>(codec),
        new CommandArgs<>(codec)
                .addKey(key)
                .addValue(value));

Calls to dispatch(…) on the synchronous API are blocking calls, calls on the asynchronous API return a RedisFuture<T> and calls on the Reactive API return an Observable<T> which flat-maps collection responses.

Using dispatch(…) allows to invoke arbitrary commands and works together within transactions and Redis Cluster. Exposing this API also allows choosing a different RedisCodec for particular operations.

CommandHandler refactoring

Command sending, buffering, encoding and receiving was refactored on a large scale. Command encoding is performed in a separate handler and outside of CommandHandler. It does not longer allocate an additional buffer to encode its arguments, but arguments are directly written to the command buffer that is used to encode single command/batch of commands. Fewer memory allocations help improving performance and do not duplicate data.

Synchronization and locking were reworked as well. The critical path used for writing commands is no longer locked exclusively but uses a shared locking with almost lock-free synchronization.

Improvements to Master/Slave connections

lettuce introduced with 4.1 a Master/Slave API which is now more dynamic. It's no longer required to connect to a Master node when using Master/Slave without Sentinel as the Master/Slave API will discover the master by itself. Providing one seed node enables dynamic lookup. The API is internally prepared for dynamic updates which are used with Redis Sentinel.

A Sentinel-managed Master/Slave setup discovers configuration changes based on Sentinel events and updates its topology accordingly.

Another change is the broader support of AWS ElastiCache Master/Slave setups. AWS ElastiCache allows various patterns for usage. One of them is the automatic failover. AWS ElastiCache exposes a connection point hostname and updates the DNS record to point to the current master node. Since the JVM has a built-in cache it's not trivial to adjust the DNS lookup and caching to the special needs which are valid only for AWS ElastiCache connections. lettuce exposes a DNS Lookup API that defaults to the JVM lookup. Lettuce ships also with DirContextDnsResolver that allows own DNS lookups using either the system-configured DNS or external DNS servers. This implementation comes without caching and is suitable for AWS ElastiCache.

Another pattern is using AWS ElastiCache slaves. Before 4.2.0, a static setup was required. Clients had to point to the appropriate node. The Master/Slave API allows specifying a set of nodes which form a static Master/Slave setup. Lettuce discovers the roles from the provided nodes and routes read/write commands according to ReadFrom settings.

If you need any support, meet lettuce at:

Google Group: https://groups.google.com/d/forum/lettuce-redis-client-users
Gitter: https://gitter.im/mp911de/lettuce
Github Issues: https://github.com/mp911de/lettuce/issues

Commands

Add support for CLUSTER BUMPEPOCH command #179
Support extended MIGRATE syntax #197
Add support for GEORADIUS STORE and STOREDIST options #199
Support SCAN in RedisCluster #201
Add support for BITFIELD command #206
Add zadd method accepting ScoredValue #210
Add support for SPOP key count #235
Add support for GEOHASH command #239
Add simple interface for custom command ...

Assets 10

30 Apr 19:40

mp911de

4.1.2.Final

ea63363

4.1.2.Final

lettuce 4.1.2 is a bugfix release.

Fixes

Add log statement for resolved address #218 (Thanks to @mzapletal)
Apply configured password/database number in MasterSlave connection #220
Lazy initialization of PauseDetector and graceful shutdown #223 (Thanks to @sf-git)
Fix RedisURI validation #229 (Thanks to @nivekastoreth)
Add latencyutils and hdrhistogram to binary distribution #231

lettuce requires a minimum of Java 8 to build and run. It is tested continuously against the latest Redis source-build.

JavaDoc: http://redis.paluch.biz/docs/api/releases/4.1.2.Final/

Assets 10

30 Apr 19:17

mp911de

3.4.3.Final

c35cfaf

3.4.3.Final

lettuce 3.4.3 is a bugfix release.

Fixes

Add log statement for resolved address #218 (Thanks to @mzapletal)
Lazy initialization of PauseDetector and graceful shutdown #223 (Thanks to @sf-git)
Fix RedisURI validation #229 (Thanks to @nivekastoreth)
Add latencyutils and hdrhistogram to binary distribution #231

lettuce requires a minimum of Java 8 to build and Java 6 run. It is tested continuously against Redis 3.0 and the unstable branch.

JavaDoc: http://redis.paluch.biz/docs/api/releases/3.4.3.Final/

Assets 10

02 Mar 15:43

mp911de

4.1.1.Final

d4dc409

4.1.1.Final

lettuce 4.1.1 is a bugfix release to fix issues with shared client resources, the shaded jar, thread interrupts and, a bug that came back to live: pfmerge invokes PFADD instead of PFMERGE.

Two issues made it also into this release that are not bugfixes: Support CLUSTER NODES with busport and Allow configuration of max redirect count for cluster connections.

Fixes

pfmerge invokes PFADD instead of PFMERGE #158
Fix NPE in when command output is null #187
Set interrupted bit after catching InterruptedException #192
Do not shut down the event executor in AbstractRedisClient #194
Remove initial call to PooledClusterConnectionProvider.closeStaleConnections #195
Use RefCounters to track open resources #196
Adjust dependency repackaging for rx-java and hdrutils in shaded jar #198 (Thanks to @CodingFabian)
Fix comparison for computationThreadPoolSize #205 (Thanks to @danhyun)

Other

Switch tests to AssertJ #13
Support CLUSTER NODES with busport #184
Allow configuration of max redirect count for cluster connections #191
Switch travis-ci to container build #203
Refactor Makefile #207

lettuce requires a minimum of Java 8 to build and run. It is tested continuously against the latest Redis source-build.

JavaDoc: http://redis.paluch.biz/docs/api/releases/4.1.1.Final/

Assets 10

02 Mar 16:06

mp911de

3.4.2.Final

b2a2168

3.4.2.Final

lettuce 3.4.2 is a bugfix release to fix issues with shared client resources and the shaded jar.

Fixes

Switch tests to AssertJ #13
Do not shut down the event executor in AbstractRedisClient #194
Remove initial call to PooledClusterConnectionProvider.closeStaleConnections #195
Use RefCounters to track open resources #196
Adjust dependency repackaging for rx-java and hdrutils in shaded jar #198 (Thanks to @CodingFabian)
Fix comparison for computationThreadPoolSize #205 (Thanks to @danhyun)

Other

Switch travis-ci to container build #203

lettuce requires a minimum of Java 8 to build and Java 6 run. It is tested
continuously against Redis 3.0 and the unstable branch.

JavaDoc: http://redis.paluch.biz/docs/api/releases/3.4.2.Final/

Assets 10

11 Feb 12:45

mp911de

3.4.1.Final

ae7ea91

3.4.1.Final

lettuce 3.4.1 is a bugfix release to fix issues with Redis Cluster and thread interrupts.

Fixes

NPE when issuing multi-exec against cluster #187 (thanks to @rovarghe)
ClusterTopologyRefresh fails with NPE on password-secured Cluster nodes if password is not set #189
Redis Cluster Node connections are not authenticated in a password protected Cluster (lettuce 3.4) #190
Set interrupted bit after catching InterruptedException #192

Javadoc: http://redis.paluch.biz/docs/api/releases/3.4.1.Final/

Assets 10

29 Jan 20:31

mp911de

4.1.Final

94a3b12

4.1.Final

lettuce 4.1 is here. This release contains numerous features and bugfixes. Lettuce 4.1 introduces reusable client-resources, an EventBus, client metrics, and support for newly introduced commands. This version works with Redis 3.2 RC3 but Redis expects a change in the format of CLUSTER NODES. So watch out for a new release of lettuce as soon as Redis 3.2 RC4 or a final is released.

lettuce is available in two major versions. The 3.x stream and the 4.x stream. Both streams are maintained.

After this release, the 4.x branch will be promoted to the default branch.
Following rules should give a guidance for the stream in which a particular change is done:

Changes affecting both streams

New Redis commands (such as HSTRLEN)
Bugfixes

Changes for the 4.x stream only

New Redis paradigms
Enriching the API (such as multi-key command execution in the Cluster API)
Technical improvements to the client (such as the Reactive API)

The 3.x stream will be maintained at least until end of 2016.

Reusable ClientResources

lettuce requires a threading infrastructure to operate. Threads are grouped within EventLoopGroups and are expensive resources. They need to be spun up and shut down. Prior to this release, each instance of RedisClient and RedisClusterClient created its own EventLoopGroups and EventExecutorGroup. If you had two instances of RedisClient or RedisClusterClient, lettuce used up to 2 * (Runtime.getRuntime().availableProcessors() * 4 * 3) threads.

Two things changed now:

Lettuce uses at least 3 threads but at most the number of available processors Runtime.getRuntime().availableProcessors() * 3 threads.
EventLoopGroups are hosted within ClientResources and can be reused across multiple RedisClient or RedisClusterClient instances

By default, each RedisClient and RedisClusterClient instance have their own, dedicated ClientResources. Shared ClientResources can be supplied upon client creation (see below). In general, it is a good idea to reuse instances of ClientResources across multiple clients.

Shared client resources are required to be shutdown once they are no longer used.

You can create instances using two different patterns:

The create() factory method

By using the create() method on DefaultClientResources you create ClientResources with default settings:

ClientResources res = DefaultClientResources.create();

RedisClient client = RedisClient.create(res);
RedisClusterClient clusterClient = RedisClusterClient.create(res, seedUris);
...
client.shutdown();
clusterClient.shutdown();

res.shutdown();

This approach fits the most needs.

Resources builder

You can build instances of DefaultClientResources by using the embedded builder. It is designed to configure the resources to your needs. The builder accepts the configuration in a fluent fashion and then creates the ClientResources at the end:

ClientResources res = new DefaultClientResources.Builder().
                        .ioThreadPoolSize(4)
                        .computationThreadPoolSize(4)
                        .build();

RedisClient client = RedisClient.create(res);
RedisClusterClient clusterClient = RedisClusterClient.create(res, seedUris);
...
client.shutdown();
clusterClient.shutdown();

res.shutdown();

A RedisClient and RedisClusterClient can be created without passing ClientResources upon creation. The resources are exclusive to the client and are managed itself by the client. When calling shutdown() of the client instance ClientResources are shut down.

`create` methods to construct the client

lettuce 4.1 introduces new create methods to create client instances. The create methods replace the deprecated constructors of RedisClient and RedisClusterClient. The create methods come with various signatures to support a conslidated style of client creation:

Create a client

RedisClient client = RedisClient.create();
RedisClusterClient clusterClient = RedisClusterClient.create(seedUris);
...

Create a client using shared ClientResources

ClientResources res = DefaultClientResources.create();
RedisClient client = RedisClient.create(res);
RedisClusterClient clusterClient = RedisClusterClient.create(res, seedUris);
...

EventBus and Client Events

lettuce introduces a new event bus to publish events. The previous client events were restricted to Connected, Disconnected and ExceptionCaught and required structural changes in the event listener. With the event bus any event type can be published. To listen to client events you need to subscribe to the EventBus which is available from the ClientResources.

RedisClient client = RedisClient.create();
EventBus eventBus = client.getResources().eventBus();

Subscription subscription = eventBus.get()
                .filter(redisEvent -> redisEvent instanceof ConnectedEvent)
                .cast(ConnectedEvent.class)
                .subscribe(e -> System.out.println(e.localAddress()));

...
subscription.unsubscribe();
client.shutdown();

The event bus uses rx-java to publish events. Following events are available:

ConnectedEvent
ConnectionActivatedEvent
DisconnectedEvent
ConnectionDeactivatedEvent
ClusterTopologyChangedEvent
CommandLatencyEvent (see Command Latency Metrics for further details)

All of the built-in events carry additional details (see JavaDoc for details).

Events are published within the scope of the EventBus instance that is by default part of the ClientResources.
The event bus will be used by multiple client instances if client resources are shared.

Listeners implementing the RedisConnectionStateListener still work.

Command Latency Metrics

Command latency metrics give insight about command execution and latencies. Metrics are collected for every completed command and are enabled by default.

Each command is tracked with:

Execution count
Latency to first response (min, max, percentiles)
Latency to complete (min, max, percentiles)

Command latencies are tracked on remote endpoint (distinction by host and port or socket path) and command type level
(GET, SET, ...). It is possible to track command latencies on a per-connection level (see DefaultCommandLatencyCollectorOptions).

Command latencies are transported using Events on the EventBus. The EventBus can be obtained from the ClientResources of the client instance. Please keep in mind that the EventBus is used for various event types. Filter on the event type if you're interested only in particular event types.

RedisClient client = RedisClient.create();
EventBus eventBus = client.getResources().eventBus();

Subscription subscription = eventBus.get()
                .filter(redisEvent -> redisEvent instanceof CommandLatencyEvent)
                .cast(CommandLatencyEvent.class)
                .subscribe(e -> System.out.println(e.getLatencies()));

The EventBus uses rx-java to publish events. This example prints the received latencies to stdout. The interval and
the collection of command latency metrics can be configured in the ClientResources.

Disabling command latency metrics

To disable metrics collection, use own ClientResources with a disabled DefaultCommandLatencyCollectorOptions:

ClientResources res = new DefaultClientResources
        .Builder()
        .commandLatencyCollectorOptions(DefaultCommandLatencyCollectorOptions.disabled())
        .build();

RedisClient client = RedisClient.create(res);

Master/Slave connections

Redis nodes can be operated in a Master/Slave setup to achieve availability and performance. Master/Slave setups can be run either Standalone or managed using Redis Sentinel. Lettuce allows to use slave nodes for read operations by using the MasterSlave API that supports both Master/Slave setups:

Redis Standalone Master/Slave (no failover)
Redis Sentinel Master/Slave (Sentinel-managed failover)

The resulting connection uses in any case the primary connection-point to dispatch non-read operations.

Redis Sentinel

Master/Slave with Redis Sentinel is very similar to regular Redis Sentinel operations. When the master fails over, a slave is promoted by Redis Sentinel to the new master and the client obtains the new topology from Redis Sentinel.

Connections to Master/Slave require one or more Redis Sentinel connection points and a master name.
The primary connection point is the Sentinel monitored master node.

Example

RedisURI sentinelUri = RedisURI.Builder.sentinel("sentinel-host", 26379, "master-name").build();
RedisClient client = RedisClient.create();

StatefulRedisMasterSlaveConnection<String, String> connection = MasterSlave.connect(client,
            new Utf8StringCodec(), sentinelUri);

connection.setReadFrom(ReadFrom.SLAVE);

connection.sync().get("key");

connection.close();
client.shutdown();

Redis Standalone

Master/Slave with Redis Standalone is very similar to regular Redis Standalone operations. A Redis Standalone Master/Slave setup is static and provides no built-in failover. Slaves are read from the Redis Master node's INFO command.

Connecting to Redis Standalone Master/Slave nodes requires to connect use the Redis Master for the RedisURI. The node used within the RedisURI is the primary connection point.

RedisURI masterUri = RedisURI.Builder.redis("master-host", 6379).build();
RedisClient client = RedisClient.create();

StatefulRedisMasterSlaveConnection<String, String> connection = MasterSlave.connect(client,
            new Utf8StringCodec(), masterUri);

connection.setReadFrom(ReadFrom.SLAVE);

connection.sync().get("key");

connection.close();
client.shutdown();

Reusable ClientResources

Two things changed now:

Lettuce uses at least 3 threads but at most the number of
available processors Runtime.getRuntime().availableProcessors() * 3 threads.
EventLoopGroups are hosted within ClientResources
and can be reused across multiple RedisClient or RedisClusterClient instances

Shared client resources are required to be shutdown once they are no longer used.

You can create instances using two different patterns:

The create() factory method

By using the create() method on DefaultClientResources you create ClientResources with default settings:

ClientResources res = DefaultClientResources.create();

RedisClient client = RedisClient.create(res);
RedisClusterClient clusterClient = RedisClusterClient.create(res, seedUris);
...
client.shutdown();
clusterClient.shutdown();

res.shutdown();

This approach fits the most needs.

Resources builder

ClientResources res = new DefaultClientResources.Builder().
                        .ioThreadPoolSize(4)
                        .computationThreadPoolSize(4)
                        .build();

RedisClient client = RedisClient.create(res);
RedisClusterClient clusterClient = RedisClusterClient.create(res, seedUris);
...
client.shutdown();
clusterClient.shutdown();

res.shutdown();

`create` methods to construct the client

Create a client

RedisClient client = RedisClient.create();
RedisClusterClient clusterClient = RedisClusterClient.create(seedUris);
...

*Create a client using shared ClientResources *

ClientResources res = DefaultClientResources.create();
RedisClient client = RedisClient.create(res);
RedisClusterClient clusterClient = RedisClusterClient.create(res, seedUris);
...

EventBus and Client Events

RedisClient client = RedisClient.create();
EventBus eventBus = client.getResources().eventBus();

Subscription subscription = eventBus.get()
                .filter(redisEvent -> redisEvent instanceof ConnectedEvent)
                .cast(ConnectedEvent.class)
                .subscribe(e -> System.out.println(e.localAddress()));

...
subscription.unsubscribe();
client.shutdown();

The event bus uses rx-java to publish events. Following events are available:

ConnectedEvent
ConnectionActivatedEvent
DisconnectedEvent
ConnectionDeactivatedEvent
ClusterTopologyChangedEvent
CommandLatencyEvent (see Command Latency Metrics for further details)

All of the built-in events carry additional details (see JavaDoc for details).

Events are published within the scope of the EventBus instance that is by default part of the ClientResources. The event bus will be used by multiple client instances if client resources are shared.

Listeners implementing the RedisConnectionStateListener still work.

Command Latency Metrics

Command latency metrics give insight about command execution and latencies. Metrics are collected for every completed command and are enabled by default.

Each command is tracked with:

Execution count
Latency to first response (min, max, percentiles)
Latency to complete (min, max, percentiles)

RedisClient client = RedisClient.create();
EventBus eventBus = client.getResources().eventBus();

Subscription subscription = eventBus.get()
                .filter(redisEvent -> redisEvent instanceof CommandLatencyEvent)
                .cast(CommandLatencyEvent.class)
                .subscribe(e -> System.out.println(e.getLatencies()));

The EventBus uses rx-java to publish events. This example prints the received latencies to stdout. The interval and the collection of command latency metrics can be configured in the ClientResources.

Disabling command latency metrics

To disable metrics collection, use own ClientResources with a disabled DefaultCommandLatencyCollectorOptions:

ClientResources res = new DefaultClientResources
        .Builder()
        .commandLatencyCollectorOptions(DefaultCommandLatencyCollectorOptions.disabled())
        .build();

RedisClient client = RedisClient.create(res);

ReadFrom Settings/Redis Cluster slave reads

The ReadFrom setting describes how lettuce routes read operations to the members of a Redis Cluster.

By default, lettuce routes its read operations to the master node. Reading from the master returns the most recent version of the data because write operations are issued to the single master node. Reading from masters guarantees strong consistency.

The ReadFrom setting can be set to one of the following presets:

MASTER Default mode. Read from the current master node.
MASTER_PREFERRED Read from the master, but if it is unavailable, read from slave nodes.
SLAVE Read from slave nodes.
NEAREST Read from any node of the cluster with the lowest latency.

Custom read settings can be implemented by extending the com.lambdaworks.redis.ReadFrom class.

Updated dependencies

netty 4.0.28.Final -> 4.0.34.Final

Enhancements

Support CLUSTER SETSLOT STABLE command #160
Support FLUSHALL [ASYNC]/FLUSHDB [ASYNC]/UNLINK commands #146
Adjust logging when running into Exceptions (exceptionCaught()) #140
Implement an EventBus system to publish events and metrics #124 (Thanks to @pulse00)
Implement a CompressionCodec for GZIP and Deflate compression #127
Provide a reusable client configuration for ThreadPools and other expensive resources #110
Use much faster JDK utility for converting an int to a byte sequence #163 (Thanks to @CodingFabian)
Cluster ReadFrom #114
Allow limiting the request queue size #115
Extend support for CLUSTER commands #111
Dispatch CLUSTER commands based on the slot #112
Support changed CLUSTER SLOTS #183

Fixes

Do not cache InetSocketAddress/SocketAddress in RedisURI #144
pfmerge invokes PFADD instead of PFMERGE #158 (Thanks to @christophstrobl)
Fix set with args method signature #159 (Thanks to @joshdurbin)
fix NOAUTH error when connecting to a cluster with password protection #171 (Thanks to @LiuFL)
Enable P...

Assets 10

11 Dec 06:58

mp911de

4.0.2.Final

4dc9bab

4.0.2.Final

This is a bugfix release for lettuce 4.0.1.Final.

Fixes

pfmerge invokes PFADD instead of PFMERGE #158 (Thanks to @christophstrobl)
Fix set with args method signature #159 (Thanks to @joshdurbin)

Assets 10

11 Dec 06:55

mp911de

3.3.2.Final

069b197

3.3.2.Final

This is a bugfix release for lettuce 3.3.1.Final.

Fixes

pfmerge invokes PFADD instead of PFMERGE #158 (Thanks to @christophstrobl)
Fix set with args method signature #159 (Thanks to @joshdurbin)

Assets 10

Releases: redis/lettuce

4.2.0.Final

Redis Cluster Publish/Subscribe

Redis Cluster and SSL

Redis Cluster Topology Discovery and Refreshing

Redis Modules

CommandHandler refactoring

Improvements to Master/Slave connections

Commands

Uh oh!

4.1.2.Final

Fixes

Uh oh!

3.4.3.Final

Fixes

Uh oh!

4.1.1.Final

Fixes

Other

Uh oh!

3.4.2.Final

Fixes

Other

Uh oh!

3.4.1.Final

Fixes

Uh oh!

4.1.Final

Reusable ClientResources

create methods to construct the client

EventBus and Client Events

Command Latency Metrics

Disabling command latency metrics

Master/Slave connections

Redis Sentinel

Redis Standalone

Uh oh!

3.4.Final

Reusable ClientResources

create methods to construct the client

EventBus and Client Events

Command Latency Metrics

Disabling command latency metrics

ReadFrom Settings/Redis Cluster slave reads

Updated dependencies

Enhancements

Fixes

Uh oh!

4.0.2.Final

Fixes

Uh oh!

3.3.2.Final

Fixes

Uh oh!

`create` methods to construct the client

`create` methods to construct the client