@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?

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.

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.

TBH, it’d be good to hear from Paul et al since they know WF best and see what ideas they might have.

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