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 <[email protected]> wrote: >> @Paul, your input would be appreciated. My reply is below. >> >> On 07 Nov 2014, at 16:47, Sanne Grinovero <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
