[infinispan-dev] Redis infinispan cache store

[Simon Paulger]

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 at redhat.com> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150827/5c3e53d7/attachment.html