Muhahahaha! Aaaaargh! Trick or Treat. Be so sweet. Give me something good to eat.

I wanted to build something cool and scary for Halloween. Here in Germany Helloween is just about to become a trend. Meet the ScareOS, a thingy to spice up Halloween.

Features

• Moving eyes (object tracking perhaps in version 2 - have to figure out how to integrate motion tracking)
• Discovers if someone is around by using a ranging sensor
• Plays Halloween sounds when it's awake
• Sleep state if no one is around for a while
• Whines when someone comes too close

I released today two betas of lettuce: 3.3.Beta1 and 4.0.Beta1. What is the difference between those versions? Both use netty and a very similar core to serve as Redis driver. The 4.0 branch introduces a Reactive API, stateful connections, improved API and command execution on multiple cluster nodes. 4.0 also introduces a set of breaking changes. The 3.x branch is supported for at least a year, new Redis commands will be supported in both branches. 4.0 is the next generation of lettuce.

lettuce 4.0.Beta2 features ReadFrom Settings. ReadFrom affects 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.

You can reduce latency or improve read throughput by distributing reads to slave members of the Redis cluster for applications that do not require fully up-to-date data. ReadFrom is set per connection, meaning you can use different connections with different ReadFrom settings.

CDI is one of the best additions to Java EE of the recent. This opinion is widely shared amongst users and integrators. CDI 1.2, the current version, was released in April, 2014. Now in mid-2015, we face the early draft review of the CDI 2.0 spec. CDI 2.0 will run on Java 8 and higher.

I'm very excited to present you lettuce 3.3.Final. Read on for the details or jump to the end to find the summary and the download links.

I released the first version of spinach, a scalable Java Disque client based on netty. spinach is built on top of the lettuce client which provides SSL and Unix domain connections in addition to plaintext connections.

Basic usage

DisqueClient client = new DisqueClient("host");
DisqueConnection<String, String> connection = client.connect().sync();
DisqueCommands<String, String> sync = connection.sync();
String jobId = sync.addjob("queue", "body", 1, TimeUnit.MINUTES);

Job<String, String> job = sync.getjob("queue");
connection.ackjob(job.getId());

Features

• Works with Java 6, 7 and 8
• synchronous and asynchronous APIs
• SSL and Unix Domain Socket connections
• Codecs (for UTF8/bit/JSON etc. representation of your data)

For complete information on spinach see the websites:

• http://github.com/mp911de/spinach
• http://spinach.paluch.biz.

Links

• Release on Github
• Artifact overview on Maven Central
• Download spinach 0.1
• Wiki
• Maven Site (Javadoc)

Maven coordinates:

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>spinach</artifactId>
    <version>0.1</version>
</dependency>

Any feedback is appreciated or create issues on GitHub.

Implementing clean architecture is amazing. A clean architecture fundamentally changes the way you create software and perform changes to existing code. The architectural style, also known as Jacobson architecture or Onion architecture, is based on the business rules. Meaning the application model and use cases. These parts become the explicit core of such an application. The core is agnostic against the database, the web, and frameworks, which are then just plugins to the application.

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.

The Geo-API of the upcoming Redis 3.2 release allows to maintain a set (backed by a Redis sorted set) of Geo points described by WGS84 coordinates. You can add and query set members using the new Geo-API. Use ZREM to remove members from the until https://github.com/antirez/redis/issues/2674 is resolved.

This release features Unix domain sockets on linux-x86_64 systems. Local connections to a Redis instance are now possible without the use of the network. A second feature with a huge impact is client options. Client options allow to control behavior on a fine-grained base. It is now possible to turn off auto-reconnect, validate the connection with a PING before activating the connection for client usage and many more.