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

[Tristan Tarrant]

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.
Bonus points if we can also make WildFly use our versions for its 
clustering stuff.

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