In May 2014, I needed a Redis client. I had to collect log events within Redis (see https://github.com/mp911de/logcapture) during integration tests. The nature of integration tests and log events is, when tests are running, a lot is logged, but after the tests the connection is idle. Several clients caused connections to run into defective states, and I did not want remote log capturing kills my integration tests. So I took the best client amongst them all and started to fix the issues that were show stoppers.
Now, about a year later, lettuce 3.2 is the most recent version, three versions were released since then. Developing lettuce is amazing. It’s by far the most advanced low-level client. There are others like Spring Data Redis or Redisson that provide high-level functionality. I’m not talking about those high-level clients. I guess, my biggest mistake was connection pooling. I was supercilious, and I was convinced, that connection pooling is a killer feature and a must. I had only my use case on my mind. @wg did not like connection pooling, too, and most probably it is the reason, why he never merged my pull request.
However, my best decision was to start working on lettuce. I learned a lot, and I was able to support nearly all Redis 3.0 features: Sentinel, Cluster and a ton of commands. The features are well received, and the downloads increase every month.
The question might arise: Where is the journey heading? What are the strategy and the roadmap?
I want lettuce to be the most easy-to-use, advanced, and, flexible Java Redis client. I want to provide a synchronous, an asynchronous and a reactive API. Spinach, the Java Disque client, is built on top of lettuce. A pull request for Spring Data Redis, upgrade lettuce to 3.2, is already in progress.
The roadmap for lettuce 4.0:
- Advanced Cluster API: Provide means to run commands on a selected set of cluster nodes
- Pipelining for specific cluster commands
- Improve RedisFuture
- Add a reactive API
- Drop Java 6 and 7 support and maintain the 3.x branch for a certain time.
- Streamline connection resources, so that users can use different API’s for the same resource
- More community feedback
I learned that plain Java futures are not flexible enough, that’s the reason, why RedisFuture
is a ListenableFuture
. Lettuce 4.0 will use CompleteableFutures
under the hood, and this will change the behavior. Currently RedisFuture.get
does not throw an exception when the command errored within Redis. The ´RedisFuture.getError´ method provides the error text. CompleteableFuture
‘s require to complete either with a result or with an exception, and that, will be a breaking change for async users.
Although downloads and the user base grow, the community around lettuce is far too small. I am grateful for every feedback and discussion on lettuce and it’s API.
I want the community to grow. I created recently the mailing list/Google Group lettuce-redis-client-users and updated the contribution readme. Github Issues and the mailing list are great starting points to contribute.