Optimal Clustered Infinispan - Hibernate configuration for multiple apps deployed on a server (Shared CacheManager vs Shared Jgroups transport)

[amitkapps]

I'm trying to setup Infinispan (with Clustered caching) as as hibernate 2nd level cache.

In my scenario I have multiple Applications deployed on a cluster of servers and I need clustered caching for each of those apps.

Here's and example of how the setup is:

1. There is a Application server cluster of 2 servers - svr1 and svr2

2. Each of these servers has multiple apps deployed on it: App1, App2

App1 & App2 both use hibernate and I need to setup clustered caching for them such that App1 on svr1 can push/pull cache updates from App1 on svr2

So far I can think of 2 ways of going about achieving this.

Option1:

Have a startup component (That runs before App1 & App2 deployment) on the app servers that creates a single Cache manager and binds it to the Jndi.

App1 and App2, simply lookup the cachemanager from the jndi and start using it.

To Achieve this, I had to put Infinispan-core and related dependencies (marshaller/river etc.) on the App Server's classpath. When trying to use it within App1/App2 I ran into

classloading issues where the marshaller was unable to unmarshal the Hibernate CacheKey when the cache contents got pushed to the secon server (I did enable lazy deserialization).

However I think its because the marshaller is on the system classpath and cannot see the Application classes (loaded via a different classloader).

I'm not sure how to go about getting this configuration to work.

Option2:

I haven't implemented this yet, but here's the description.

Let each Application - App1/App2 create its own CacheManager and use it, but let the JGroups transport be configured as a shared transport ().

JGroups jar will sit on the app servers classpath and the Transport can be shared across App1/App2 when infinispan creates the apps' associated Jgroups channels for their cache managers.

I kind of favor the Option2 approach.

Do you think that Option2 would be as efficient (resource usage wise) as Option1?

Would you suggest a different way to achieve clustered caching with optimized resource usage (my need is to provide clustered caching capability to several distinct applications running

on a weblogic cluster.)

[galder.zamarreno]

Re Option 1: If you can't marshall Hibernate's CacheKey, that's quite likely cos Hibernate 3.5.x or higher is not available in its classloader classpath. You should check what weblogic reqs are in this area.

Re Option 2: This won't solve your problem in Option 1. Is just another way to deploy JGroups layer

I think it's a bit early for you to be making this decision. Normally, you decide to have the same JGroups layer or a different one depending on your deployment/runtime/performance requirements. IOW, if you wanna reduce the number of mcast address/ports to mantain, you use option 2. If each app is very different and you need to tweak JGroups in a different way depending on the app, then Option 1.

[amitkapps]

Option1: If i were to add the hibernate libraries also as part of the system classloader i would essentially force all applications to a particular version of Hibernate.

Option2: With option 2 I would keep the marshalling and hibernate libraries as part of the application package(ear/war) and only the JGroups component in the system class path. That way the transport could be shared across different applications on the app-server at the expense of each app creating its own Cache manager. I read in the Infinispan docs that Cache manager component was relatively heavy and sharing that was recommended, and my question then would be if the heaviness of the Cache manager was mainly based on the heaviness of the JGroups' transport layer or because of its own sub component etc. With the shared transport is it still that heavy? IF so what sub components are we talking about? Thread pools etc... and how bad is that to have multiple copies of those (We'd be looking at 5-10 copies of those on an app server coz I'll have those many differnt apps needing the clustered caching feature.)

I Understand that if applications have different transport requirements then it means a different JGroups layer for them and going with OPtions 2 i'm not restricted with that either - I can still have a different transport definitions (I do not use the same singleton name that I use for the other shared transport).

[galder.zamarreno]

Option 2: It's heavy cos you have a JGroups stack per cache manager, but the main issue is maintance of bind ports, multicast addresses...etc. 5-10 is prob too much. We used to have such set up in AS 4 and it was a nightmare to maintain. 2-3 would be top IMO.