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

[Sanne Grinovero]

On 10 November 2014 12:50, Galder Zamarreño <galder at redhat.com> wrote:
> @Paul, your input would be appreciated. My reply is below.
>
> On 07 Nov 2014, at 16:47, Sanne Grinovero <sanne at 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?

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