Yes, we would be very interested. Check out the Infinispan cachestore archetype [1] to get things started, and ask here or on IRC on #infinispan for help, if you need more information. Tristan [1] https://github.com/infinispan/infinispan-cachestore-archetype On 28/07/2015 22:43, Simon Paulger wrote: > Hi, > > I'm interested in developing inifinispan integration with Redis for use > in JBoss. Before working on JBoss, I first need to add the capability to > Infinispan itself. > > Is this an enhancement that the infinispan community would be interested in? > > Regards, > Simon > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- 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

Let's start with a separate repo to begin with. As for third party clients, choose the one you feel is the best. Thanks for looking into this Tristan On 29/07/2015 20:31, Simon Paulger wrote: > Hi Tristan, > > With regards to project repositories, should I add the code to a fork of > the main infinispan project or create a standalone repository as per > hbase, jdbm, etc? > > And I presume there's no objections to using a third party Redis client? > I was thinking Jedis (https://github.com/xetorthio/jedis - MIT license, > currently maintained). > > Thanks, > Simon > > On 29 July 2015 at 10:47, Tristan Tarrant <ttarrant(a)redhat.com > <mailto:ttarrant@redhat.com>> wrote: > > Yes, we would be very interested. Check out the Infinispan cachestore > archetype [1] to get things started, and ask here or on IRC on > #infinispan for help, if you need more information. > > > Tristan > > [1] https://github.com/infinispan/infinispan-cachestore-archetype > > On 28/07/2015 22:43, Simon Paulger wrote: > > Hi, > > > > I'm interested in developing inifinispan integration with Redis > for use > > in JBoss. Before working on JBoss, I first need to add the > capability to > > Infinispan itself. > > > > Is this an enhancement that the infinispan community would be > interested in? > > > > Regards, > > Simon > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto: infinispan-dev(a)lists.jboss.org&gt; > 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 > -- 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

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

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