@Paul, your input would be appreciated. My reply is below. On 07 Nov 2014, at 16:47, Sanne Grinovero <sa...@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? 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. Cheers, > > Sanne > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
