On 11 Nov 2014, at 16:12, Tristan Tarrant <[email protected]> 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 <[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 -- Galder Zamarreño [email protected] twitter.com/galderz _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
