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