
Show HN: Redis Java 8 Client and Command Executor - jamespedwards
https://github.com/jamespedwards42/jedipus
======
mdobryakov
Could you please explain what is the difference between your Redis client and
[https://github.com/mp911de/lettuce](https://github.com/mp911de/lettuce) ?

~~~
jamespedwards
Lettuce uses such a different programming style I never tried it out. If you
are looking for a Java Redis client, please try out all three: Lettuce, Jedis
and Jedipus and pick the one that fits your taste.

Because I'm not familiar with Lettuce, I'm just going to list my personal
subjective design goals:

* Robust transient error handling and retries.

* Get out of the users way when sending a command and its arguments. The client should get the request data onto the wire as soon as possible. The client should not force the user to use any data structures for representing requests or responses.

* Efficient pipelining support. Every client re-uses a single ArrayDequeue to optionally hold pending responses; no other data structures are created per request. See this gist for pipelined bulk loading [https://gist.github.com/jamespedwards42/d03482c4b3515f78d1db...](https://gist.github.com/jamespedwards42/d03482c4b3515f78d1dbf9d7b092711e).

* Frequent point releases in-sync with the Redis unstable branch. For example the new TOUCH command was added and released a day after being pushed to github at antirez/redis:unstable.

* Redis Cluster focused. you can use just the client or pooled client executer, but the cluster executor is the real reason to use this library. The focus here is safety: partition handling and minimal locking only applied to migrating/unavailable slots. As well as performance (under the hood --> clientPools[slot].getClient). Also, things like load balancing requests across all of your nodes for a key/slot is nice :)

* Make the development experience more enjoyable by using Java 8, Gradle and Docker. Hopefully this will attract other developers to the project so that a healthy community can grow. Goal is to move to Java 9 on rc1 in November, and to the Gradle component model and Kotlin instead of Groovy whenever that is ready as well.

* Zero dependencies, none, nada.

* I don't think this one really matters, but it is a pet peeve of mine. Avoid auto boxing by deserializing primitive long's directly from the socket input stream buffer.

------
WatchDog
My very limited use of jedis felt pretty clunky, this looks like it could be a
bit nicer to use. Next time I need to interact with redis I will give it a go.

~~~
jamespedwards
Thanks, happy to work out any kinks you hit with the api experience.

