java - Jedis and Lettuce async abilities -

i using redis akka need no blocking calls. lettuce has async-future call built it. jedis recommended client redis. can tell me if using both of them right way. if 1 better.

jedis using static jedis connection pool con , using akka future callback process result. concern here when use thread (callable) result thread going block result. while lettuce might have more efficient way of doing this.

 private final class onsuccessextension extends onsuccess<string> {             private final actorref senderactorref;             private final object message;             @override             public void onsuccess(string valueredis) throws throwable {                 log.info(getcontext().dispatcher().tostring());                 senderactorref.tell((string) message, actorref.nosender());             }              public onsuccessextension(actorref senderactorref,object message) {                     this.senderactorref = senderactorref;                     this.message=message;                 }         }         actorref senderactorref = getsender(); //never close on future             if (message instanceof string) {         future<string> f =akka.dispatch.futures.future(new callable<string>() {                     public string call() {                         string result;                         try(jedis jedis=jediswrapper.redispool.getresource()) {                             result = jedis.get("name");                         }                         return result;                     }                 }, ex);                 f.onsuccess(new onsuccessextension(senderactorref,message), ex);     } 

lettuce

executorservice executorservice = executors.newfixedthreadpool(10); public void onreceive(object message) throws exception {         actorref senderactorref = getsender(); //never close on future         if (message instanceof string) {              final redisfuture<string> future = lettuce.connection.get("name");             future.addlistener(new runnable() {                 final actorref sender = senderactorref;                 final string msg =(string) message;                 @override                 public void run() {                     try {                         string value = future.get();                         log.info(value);                         sender.tell(message, actorref.nosender());                     } catch (exception e) {                     }                 }             }, executorservice); 

if lettuce better option async calls. type of executor should go in production environment. if possible can use akka dispatcher execution context letture future call.

there no 1 answer question because depends.

jedis , lettuce both mature clients. complete list of java clients, there redisson, adds layer of abstraction (collection/queue/lock/... interfaces instead of raw redis commands).

it pretty depends on how you're working clients. in general, redis single-threaded in terms of data access, benefit gain concurrency offloading protocol , i/o work different threads. not true lettuce , redisson since use netty under hood (netty binds 1 socket channel particular event loop thread).

with jedis, can use 1 connection 1 thread @ time. correlates nicely akka actor model because 1 actor instance occupied 1 thread @ time.

on other side, need jedis connections threads deal particular actor. if start sharing jedis connections across different actors, either go connection pooling, or need have dedicated jedis connection per actor instance. please keep in mind need take care of reconnection (once redis connection broken) yourself.

with redisson , lettuce, transparent reconnection if wish (that's default value lettuce, not sure redisson).

by using lettuce , redisson can share 1 connection amongst actors because thread-safe. cannot share 1 lettuce connection in 2 cases:

1. blocking operations (since block other users of connection)
2. transactions (multi/exec, since mix different operations transactions , thing not want so)

jedis has no async interface, you're required yourself. that's feasible, , did similar mongodb, offloading/decoupling i/o part other actors. can use approach code, you're not required provide own executor service because non-blocking operations in runnable listener.

with lettuce 4.0 you'll java 8 support (which way better in terms of async api because of completionstage interface), , can use rxjava (reactive programming) approach concurrency.

lettuce not opinionated on concurrency model. allows use according needs, except plain future/listenablefuture api of java 6/7 , guava not nice use.

hth, mark