[infinispan-dev] Redis infinispan cache store

[Galder Zamarreno]

Great stuff Simon, thanks for contributing that! :D

--
Galder Zamarreño
Infinispan, Red Hat

----- Original Message -----
> 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
> >
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev