views:

1206

answers:

5

Hi All,

I'm currently investigating how to use the RMI distribution option in ehcache. I've configured properly ehcache.xml and replication seems to work fine. However I've 2 questions:

-> It seems ehcache/ hibernate creates 1 cache per Entity. This is fine, however when replication is in place it create 1 thread / cache to replicate. Is this the intended behavious ? As our domain is big, it creates about 300 threads, which seems to me really big

-> Another nasty consequence is that the heartbeat messagre seems to aggregate all of those cache names. From what I saw the message should fit in 1500 bytes, which it does not, which leads to this message in my logs: Heartbeat is not working. Configure fewer caches for replication. Size is 1747 but should be no greater than1500. Any idea on how this could be changed ?

Thanks a lot for your help

+1  A: 

Did you consider JBossCache as an alternative to EHcache? JBossCache has distributed transactions and is well-tested for high-loads. It has lower-level replication mechanisms which can allow you to use UDP or TCP multicasting/broadcasting replication.

Artem
A: 

Is jms replication an option?

(I have been looking in to using it with async behavior, it works nice. Documentation was wrong so I had to check the source code to see the actual attributes needed to configure it properly. Good thing with jms is that if you have that infrastructure set up you don't have to configure any firewalls and so on to let it through.)

Konstantin
JMS is no where near real time, any transport that updates a cache must be real time.
mP
If you just set up a defaultcache, then that will be cloned to create each necessary entity cache. AFAIK, you will NOT get "one big cache".
Alex Miller
+2  A: 

Did you consider EHCache over Terracotta? Take a look at Terracotta Hibernate Integration and Terracotta EHCache Integration

Importantly the Terracotta distributed EHCache is coherent - all nodes have the same view of the cache. This is very important for one of the applications I worked with.

Take a look. It works like a charm for us.

/RS

+1  A: 

We already have one hack where we have our own custom copy of the hibernate EhCacheProvider that overrides buildCache() to create our own Cache objects with shortened names (the hash of the name). This gets around the 1500 limit. We keep a hashmap of the original names with the hash names for reverse lookup.

We did this a while ago and have been using it in production.

We also looked at your other issue to have a single replicator thread. First we copied RMICacheReplicatorFactory and changed createCacheEventListener() to return our copy of RMIAsynchronousCacheReplicator that we modified by making the replicationThread field static and then making the necassary fixes for that. We didn't get around to testing it thoroughly or putting it in production, but are looking at it again which is how I found this post :)

campers
The 1500 limit is addressed with https://jira.terracotta.org/jira/browse/EHC-424 for upcoming Ehcache 1.7.1.
Alex Miller
A: 

By the way, the 1500 byte limit has been addressed for the Ehcache 1.7.1 release of ehcache-core. See EHC-424.

Alex Miller