[infinispan-dev] Feature request: manage and share a CacheManager across deployments on WildFly

[Galder Zamarreño]

On 11 Nov 2014, at 16:12, Tristan Tarrant <ttarrant at redhat.com> wrote:

> My proposal:
> 
> make the Infinispan + JGroups subsystems which we develop for Infinispan 
> Server installable in any instance of WildFly.
> They would obviously use a different namespace & slot to avoid conflict.

^ +1

> Bonus points if we can also make WildFly use our versions for its 
> clustering stuff.

If we can find an easy way to test this, then yeah :)

> 
> Tristan
> 
> On 11/11/14 14:57, Sanne Grinovero wrote:
>> On 10 November 2014 12:50, Galder Zamarreño <galder at redhat.com> wrote:
>>> @Paul, your input would be appreciated. My reply is below.
>>> 
>>> On 07 Nov 2014, at 16:47, Sanne Grinovero <sanne at infinispan.org> wrote:
>>> 
>>>> I'm witnessing users of Hibernate Search who say they deploy several
>>>> dozens of JPA applications using Hibernate Search in a single
>>>> container, and when evaluating usage of Infnispan for index storage
>>>> they would like them all to share the CacheManager, rather than
>>>> starting a new CacheManager for each and then have to worry about
>>>> things like JGroups isolation or rather reuse via FORK.
>>>> 
>>>> This is easy to achieve by configuring the CacheManager in the WildFly
>>>> configuration, and then looking it up by JNDI name.. but is not easy
>>>> at all to achieve if you want to use the custom modules which we
>>>> deliver to allow using a different Infinispan version of what's
>>>> included in WildFly.
>>>> 
>>>> That's nasty, because we ultimately want people to use our modules and
>>>> leave the ones in WildFly for its internal usage.
>>>> 
>>>> It would be nice if the team could include in the modules.zip a way to
>>>> pre-start configured caches, and instructions to mark their
>>>> deployments as depending on this service. Would be useful to then
>>>> connect this to monitoring too..
>>> If all Hibernate Search apps are using the same cache manager, won’t they have cache conflicts? Or are these caches named in such way that they can run within a single cache manager?
>> Like different deployment might want to share the same database,
>> sometimes people want to share the index. It should be up to
>> configuration to be able to isolate vs share an index.. and we're
>> flexible about that as you can use different cache names, or different
>> index names sharing the same caches.
>> 
>>> The simplest thing I can think of to achieve this would be for an optional service to start a cache manager with a given configuration, and bind that to JNDI.  That would be something we can potentially provide, with JMX monitoring at best.
>> +1
>> That's what I think we're missing. Sounds like very useful and not a
>> big effort to provide.
>> 
>>> However, if you want these cache manager to be registered into Wildfly’s domain model for better monitoring, I don’t really know if this would be something we can just provide without any serious hooks into Wildfly :|, and then it all gets quite complicated IMO because you need to start maintaining yet another integration layer with Wildfly.
>> Keep in mind that we want people to use the Infinispan jars, not the
>> WildFly version of Infinispan when it comes to custom/direct usage.
>> For example for EAP users, it's unsupported to use the included
>> Infinispan version so going via the standard configuration files is
>> not an option. So I'm not sure which integration options we have: I'm
>> expecting this to be provided purely as an add-on strongly coupled to
>> the Infinispan release. So I agree it should be highly decoupled from
>> WildFly code.
>> 
>>> TBH, it’d be good to hear from Paul et al since they know WF best and see what ideas they might have.
>> +1 Looking forward.
>> 
>> Sanne
>> 
>> _______________________________________________
>> 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


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz