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

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(a)redhat.com&gt; wrote: >> @Paul, your input would be appreciated. My reply is below. >> >> On 07 Nov 2014, at 16:47, Sanne Grinovero <sanne(a)infinispan.org&gt; 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(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