[infinispan-dev] Redis infinispan cache store

[Simon Paulger]

You're welcome :)

Sent from my iPhone

> On 3 Sep 2015, at 10:53, Galder Zamarreno <galder at redhat.com> wrote:
> 
> 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
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev