Re: [infinispan-dev] Redis infinispan cache store

I have added a license as well as configuration snippets on use. I think its probably best for infinispan if it were transferred to the Infinispan org. Looking forward to your feedback. Thanks, Simon On 27 August 2015 at 12:21, Tristan Tarrant <ttarrant(a)redhat.com&gt; wrote: > Thank you Simon, this is excellent news ! > > On 27/08/2015 12:49, Simon Paulger wrote: > > Hi, > > > > This is now done and is available to see here: > > https://github.com/spaulg/infinispan-cachestore-redis. I used the remote > > store within the infinispan repo as a base of reference. > > I see there is no license associated with that repo. I think you should > add one. > Would like the repo to become officially owned by the Infinispan > organization ? > > > > > There are some points that my be worth further discussion. They are: > > 1. the cache loader size method return type is limited to int. Redis > > servers can hold much more than Integer.MAX_VALUE and the Jedis client > > method for counting items on the Redis server returns longs for each > > server, which in addition must be totalled up for each server if using a > > Redis cluster topology. To get around this I am checking for a long over > > Integer.MAX_VALUE and logging a warn, then returning Integer.MAX_VALUE. > > This is a last-minute change we could do in Infinispan 8's > AdvancedCacheLoader. > > > 2. Redis handles expiration. I am using lifespan to immediately set the > > expiration of the cache entry in Redis, and when that lifespan is > > reached the item is immediately purged by Redis itself. This means, > > there is no idle time, and there is no purge method implementation. > > Good :) > > > 3. A few unit tests around expiration had to be disabled as they require > > changes to time. As expiration is handled by Redis, I would have to > > change the system time to make Redis force expiration. For now, they are > > just disabled. > > Absolutely reasonable. > > > > I have built it against the Jedis client. I also tried 2 other clients, > > lettuce and redisson, but felt that Jedis gave the best implementation > > as a) it didn't try to do too much (by this I mean running background > > monitoring threads that try to detect failure and perform automatic > > failover of Redis slaves) and b) had all the API features I needed to > > make the implementation work efficiently. > > > > Jedis supports 3 main modes of operation. They are, single server, Redis > > sentinel and Redis cluster. Redis versions that should be supported are > > 2.8+ and 3.0+. > > > > I haven't tested this beyond the unit tests distributed with Infinispan > > which are starting full Redis servers in single server, sentinel and > > cluster configurations to run the tests, but I am hoping to start > > working on getting integration in to Wildfly 10, which I can test with a > > cache container for web sessions and a simple counter web app. > > I will take a look at the code. > > Thanks again for this awesome contribution. > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev