I want to cluster EHCache in Play Framework 2.x web application in several node. Why everyone recommend to avoid to use EHCache as a distributed cache in Play 2.x clustered web application?
I use nginx proxy to serve request across Play node and i want to make default EHCache of each node share its content.
Well according to this EHCache page, using EHCache in distributed mode is a commercial product. So if you want to use a free distributed cache, you need something different like Memcached or Redis.
My experience deploying a (Java)Play 2.2.3 to Amazon EC2 was terrible with EHCache. It requires a few workarounds with the localhost resolve (going su for each of your nodes - hard work when you have a few dozens of servers) and regardless, being free only for standalone version without ostensively letting us know upfront is a big no-no for me. I'm done with EHCache.
Edit: moved to Redis in 2015 (thanks #Traveler)
I am not aware of any Play Framework issues here, but the use of ehcache 2.x should fine as you can set it up with JGroups (faster than RMI) and use invalidation mode (infinispan slang).
Invalidation is a clustered mode that does not actually share any data at all, but simply aims to remove data that may be stale from remote caches. This cache mode only makes sense if you have another, permanent store for your data.
In ehcache 2.x you can set up invalidation mode with replicatePuts=false in your jgroups config.
In ehcache 3.x they do not have such a mode. You have to set up a commercial Terracotta server which is a distributed cache. So all date is moved between nodes and the terracotta server.
We tried it once and failed terribly.
As ehcache2.x is no longer active we just switched to Infinispan which has all features of ehcache2.x and a lot more.
So my recommendation: Use ehcache 2.x or infinispan. Do not use ehcache 3.x
Related
We have a solution which uses the Apache Ignite-provided In-Memory Data Grid as a distributed cache. For newer projects, we ended up using Spring, and as such we wished homogenize our software ecosystem and using Spring for the first solution as well. In addition, we do not use all the features of Ignite to excuse its use (discovery, caching).
Since we currently only use a limited subset of features from Ignite, we are basically looking for a self-managed application-level distributed cache solution (similar to what Ignite provides). This means that dedicated caching infrastructure like Redis, Memcached, etc. is not what we want.
I've researched the topic somewhat and found that there are some possible alternatives like:
Tayzgrid - Last update seems to be quite some time ago, not sure if still actively maintained
Druid - Still incubating, and I have also read that new releases being somewhat broken was not that uncommon
Hazelcast - Seems like the best choice given its maturity and the existence of Spring Data Hazelcast, though I am unsure what the level of support is here.
Has anyone has experience with integrating one of the above IMDGs (aside from Ignite) with Spring Cache? Any pointers in the right direction would be greatly appreciated.
You can use Redisson - Redis Java client with features of
In-Memory Data Grid. It also implements Spring Data support. Here is the documentation.
Hazelcast has official support for Spring Data Hazelcast and also this module has many users as now. I can also suggest you to have a look at the resources below:
Using Hazelcast with Spring Data
Getting Started with Microservices Using Hazelcast IMDG and Spring Boot
I want to try Ehcache in distributed form. Can someone suggest me if EHcache (Not the BigMemoryMax) works in distributed mode.
I am looking for only open source product. I am not looking to buy a Bigmemory Max or Terracota server, which will give me a off heap access, which i dont need as of now.
If so, please provide the version, url and some guide/examples to implement distributed Ehcache.
Thanks...
Ehcache website is your best starting point:
Ehcache 2.10.x has open source clustering support with Terracotta 4.3.x
Ehcache 3.1.x has open source clustering support with Terracotta 5
What is the difference between the Ehcache and Guava Cache? In which scenarios would I use which type of caching?
Note: I am a developer working on Ehcache
The answer to your question depends on which features your cache needs to have inside your application.
Guava caches have all the basic caching features.
Ehcache has more advanced features - see 2.x line or upcoming 3.x line
Multi tier caching (disk in 2.x, offheap + disk in 3.x)
Clustering (2.x for now, soon in 3.x)
Refresh ahead or scheduled refresh (2.x for now)
JSR-107 API
So my advice is to look at your needs, play with both and then decide.
I am afraid I have got some pretty basic questions about ehcache. I would like to use caching mechanism on clustered Glassfish without any significant infrastrucure.
As I know using ditributed cache with ehcache means that I have to use the terracotta server array, don't?
I am not so experienced in caching so could I use the ehcache on clustered glassfish that I just put some JAR into the classpath of Glassfish or deploy a WAR or something onto Glassfish and that's it? Do I have to use an external cache server anyway?
The replicated cache in ehcache doesn't need the terracotta server array, do it?
I would like to store a java Map object in the store which is going to be changed quite often. In this case the replicated cache is not best choice, as I know. The Hazelcast distributed cache needs any external cache server?
Thank you very much for your help in advance!
Have a nice day, experts!
Hazelcast doesn't need any externel server if you are running Java.
Basically add hazelcast.jar into your classpath. And from your application creata an Hazelcast instance:
HazelcastInstance hazelcast = Hazelcast.newHazelcastInstance(new Config());
then to get a distributed map:
Map map = hazelcast.getMap("myMap");
that's it. In this example I provided the default config which uses Multicast to discovery of the nodes. You can update and change any parameter.
For more information see Quick Start Tutorial
The replication feature in Ehcache does not require any server. You simply add the Ehcache jar to your web application and configure Ehcache to replicate to all cluster nodes. You can choose whether to automatically discover all GlassFish nodes using multicast or you can manually tell Ehcache where to find the other nodes. You can find the Ehcache replication configuration instructions here: http://ehcache.org/documentation/replication/rmi-replicated-caching#configuring-the-peer-provider
Hazelcast works similarly. See here for documentation: http://hazelcast.org/docs/3.0/manual/html/ch12s02.html
Hi I have one Grails application, it uses Spring cache. I want to clone it (say APP_A and APP_B) and deploy on separate it as each access different DB and has some different configuration.
Currently I have two copy of Jetty servers (JETTY_A, JETTY_B. different port). I put APP_A in Jetty_A and APP_B in Jetty_B.
I'm not familiar with Spring cache.
Is this deployment save? I mean, will there be any mix of cache between both? Because both using the same code base. So, the cache will use the same key name.
#cacheable("someCache")
SpringCache uses EHCache under the covers. The caches are in-process caches and they do not affect caches running in other processes on the same machine, unless you had explicitly configured distributed caching.
As #KenLiu said in his answer, Spring Cache is strictly in-process when using EHCache as it's cache provider. Since you are working with Grails, however, there are better alternatives that will require only minimal changes.
The Grails Cache Plugin is a offers a Spring Cache API-compatible cache abstraction over a number of (plugable) cache providers, including some, like the Redis provider, that allow you to cache between processes (and entire machines) very easily.