Lakshmi, I've used Jedis before with Storm and Java but not with Akka/Scala. I think Jedis the most popular and well supported Java driver for Redis.
I think you can use Jedis from Akka (Java) but as far as my knowledge goes Jedis is a *blocking* driver. On the other hand, there are many Scala-based drivers (e.g., Rediscala ) that are truly non-blocking and asynchronous making them perfect for using with Akka, esp. if you care about performance, resource utilization and fault tolerance. There are other great features that you get Rediscala. For example, it automatically handles disconnects and reconnects automatically. Just to give you an example, recently I had to upgrade the Redis version for which I had to shutdown Redis. I never brought down my Akka actors. After the upgrade the Akka actors connected back again without any problems. I think if you have many micro services connecting a Redis instance this is a very powerful feature. I'm sure others who have more experience with Java and Redis can tell you more. HTH -Soumya On Thursday, July 31, 2014 10:47:40 AM UTC-4, lakshmi wrote: > > Soumya, > > Thanks for your response. I work with Luis on this. We are currently using > Java, and have used Jedis for redis access. Do you have any suggestions for > Java-based redis clients that work well for Akka? > > lakshmi > > > On Wednesday, July 30, 2014 8:48:18 AM UTC-7, Luis Medina wrote: >> >> Hi everyone, >> >> My company is planning to use Akka for a new feature that we're working >> on and we want to run our design by a few set of eyes from the Akka >> community just to make sure that what we're doing makes sense and also to >> get some feedback and see if perhaps there are other ways of doing things. >> >> The new service that we're building will involve accessing 3 different >> Redis databases to both persist and retrieve data. We can call these 3 >> databases: >> >> TopicDB - holds "topics" that are added/removed. >> StatusDB - holds the current status of a topic. Every topic is added to >> this db for tracking its status. Topics are added/updated but never removed. >> RequestDB - holds a "request" queue. Every topic generates a request in >> this db, that can also be removed. >> >> Basically additions or removals to the TopicDB are driven by an external >> application which must then direct the updates to the other 2 dbs as >> appropriate. >> >> We're planning on having a setup such that for each db there will be what >> we call a RedisSyncActor which, as the name implies, will sync up with the >> particular database that it corresponds to. In order to do this syncing, >> each of these RedisSyncActors will have at most 2 children, a >> RedisPersisterActor and a RedisListenerActor which will persist data into >> Redis and will receive data from Redis respectively. >> >> <https://lh4.googleusercontent.com/-coQA-XEkgJw/U9kTQiTcPMI/AAAAAAAAAI4/jB4mhcMNehw/s1600/image1.png> >> >> >> Now, earlier I said at most because in reality, every Redis database will >> not necessarily make use of both of each children. Based on our >> requirements, the setup will look like this where the RequestDB is the only >> one with both a RedisPersisterActor and a RedisListenerActor while the >> TopicDB only has a RedisListenerActor and the StatusDB only has a >> RedisPersisterActor. >> >> <https://lh3.googleusercontent.com/-AyDu7Pf7w1Q/U9kTWDp9BBI/AAAAAAAAAJA/s7aIYLgDmco/s1600/image2.png> >> >> >> Now, in terms of the data flow and interactions between the actors, this >> will look something like this: >> >> <https://lh5.googleusercontent.com/-eIJNHIc3EEs/U9kTaxgILsI/AAAAAAAAAJI/50Z1o6ABHgs/s1600/image3.png> >> >> >> 1. Whenever the TopicDB is changed by adding or removing what we call >> "topics", the TopicRedisListenerActor will pick up on these changes by >> using the pub/sub feature that Redis provides. >> >> 2. Once the TopicRedisListenerActor receives these changes it will send >> them in 2 directions: >> >> a. Regardless of what type of topic change it received (ie. a topic that >> was added, a topic that was removed, etc), the TopicRedisListenerActor will >> send it back to its TopicRedisSyncActor parent who will in turn send it off >> to the StatusRedisSyncActor that handles the StatusDB. This >> StatusRedisSyncActor will then forward the topic changes to its >> StatusRedisPersisterActor child so that the change can be persisted to the >> StatusDB. >> >> >> >> b. Secondly, if the topic change indicates that a topic was removed from >> the TopicDB, the TopicRedisListenerActor will send a "RemoveTopic" message >> to the TopicRedisSyncActor. This TopicRedisSyncActor will then forward the >> change to the RequestRedisSyncActor so that the RequestDB can remove the >> topic as well. >> >> >> 3. Depending on whether or not StatusDB already knows about the id of the >> topic changes that it receives, this will cause particular updates to >> happen in the database. If the topic change reflected the creation of a new >> topic, then a new entry will be added to the StatusDB and the >> StatusRedisPersisterActor will send back a reply to its >> StatusRedisSyncActor parent containing the topic and informing it of this >> action. >> >> 4. If the StatusRedisSyncActor receives a notification from its >> StatusRedisPersisterActor that a new entry was added to the StatusDB then >> it will send off this topic to ConverterActor which will convert the >> "topic" into what we call a "request". >> >> 5. Afterwards the ConverterActor will send this newly converted request >> off to the RequestRedisSyncActor. This RequestRedisSyncActor will then send >> the request to its RequestRedisPersisterActor child so that it can be >> persisted into the RequestDB. >> >> 6. The RequestRedisSyncActor also has a RequestRedisListenerActor which >> listens for changes that occur in the RequestDB. In this case, it will pick >> up the fact that a new request was added to the RequestDB by the >> RequestRedisPersisterActor in step 5 and it will send if off to other parts >> of the service for further processing. >> >> As you can see there is quite a lot going on so we want to be sure we're >> on the right track. >> >> >> A question that we had is: >> >> Are we creating too many Redis-related actors, and is there a more >> generic way to organize the Redis persisting and listening functionality >> for the 3 databases? Initially we expect the system to have somewhat of a >> light load, with very few changes a second in the TopicDB, but this could >> change as the system evolves. >> >> Luis >> > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
