I want to dynamically change the configuration of the EhCache instance we're using, specifically the maxElementsInMemory setting. We are using EhCache 1.5 and I can see that it is possible API-wise:
cache.getCacheConfiguration().setMaxElementsInMemory(num);
But the documentation of EhCache says:
After a Cache has been started its
configuration is not generally
changeable. However, since Ehcache
2.0, certain aspects of cache configuration can modified dynamically
at runtime...
So my question is: can I use this API in EhCache 1.5 or is it not guaranteed to work?
Thanks.
There are only certain properties you can modify (see Modifying Ehcache configuration at runtime), maxElementsInMemory should be one of them... for me that works in ehcache 2.4!
As per Ehcache 2.8, this is possible:
Cache cache = manager.getCache("sampleCache");
CacheConfiguration config = cache.getCacheConfiguration();
config.setTimeToIdleSeconds(60);
config.setTimeToLiveSeconds(120);
config.setmaxEntriesLocalHeap(10000);
config.setmaxEntriesLocalDisk(1000000);
source:
http://www.ehcache.org/documentation/2.8/configuration/configuration#dynamically-changing-cache-configuration
Related
I have tried Hazelcast as cache (using #Cacheable and #CacheEvict) with Spring Boot (using hazelcast-spring artifact in Spring boot 1.5.2.RELEASE) and my application crashed because it ran out of memory. I have two questions:
1) Default behaviour seems to be filling all the cache until there is no more memory and then throw an exception. Am I right? It looks weird to me that there is no default LRU o LFU criteria for caches.
2) How can I configure in hazelcast.xml max size, ttl, etc for ALL maps in my application? (Something like a default config and then extend it for particular maps)
Thanks.
#italktothewind
1 - By default, there is no eviction configured, either time or size based. But you can configure any of them or both. Please see http://docs.hazelcast.org/docs/latest-development/manual/html/Distributed_Data_Structures/Map/Map_Eviction.html
2 - If you configure the default map & no special config per map, then all maps will share the same config. But if you decide to add a map specific config, then you need to add all necessary config options since it won't inherit the other non-configured params from default map config.
I've got an application that uses Spring Cache (Ehcache), but now we need to add a 2nd node (same application). Can the cache be shared between the nodes or each with their own instance but synched?
Or do I need to look at a different solution?
Thanks.
That depends on your cache implementation - not on Spring, which only provides an abstract caching API. You are using EhCache as your caching implementation, which comes with a Terracotta server for basic clustering support and is open source. See http://www.ehcache.org/documentation/3.1/clustered-cache.html#clustering-concepts for more details
I need to implement Ehcache in a project that uses Spring version 3.1 and Websphere. I tried to google something about this topic but I could'nt find anything. Have you guys ever used those three tools together? Thanks in advance.
As per EhCache docs,It will NOT detect Websphere Transaction Manager automatically,.
Automatically Detected Transaction Managers
Ehcache automatically detects and uses the following transaction
managers in the following order:
GenericJNDI (e.g. Glassfish, JBoss, JTOM and any others that register
themselves in JNDI at the standard location of
java:/TransactionManager
Weblogic (since 2.4.0)
Bitronix
Atomikos
No configuration is required; they work out of the box. The first found
is used.
And you can configure it as below.
If your Transaction Manager is not in the above list or you wish to
change the priority, provide your own lookup class based on an
implementation of net.sf.ehcache.transaction.manager.TransactionManagerLookup and
specify it in place of the DefaultTransactionManagerLookup in
ehcache.xml:
<transactionManagerLookup
class= "com.mycompany.transaction.manager.MyTransactionManagerLookupClass"
properties="" propertySeparator=":"/>
And to integrate & Use Spring with EhCache, refer this link
From Spring docs,
36.3 Declarative annotation-based caching For caching declaration, the abstraction provides a set of Java annotations:
#Cacheable triggers cache population #CacheEvict triggers cache eviction
#CachePut updates the cache without interfering with the method execution
#Caching regroups multiple cache operations to be applied on a
method
#CacheConfig shares some common cache-related settings at class-level
So I'm upgrading a spring boot project to use the latest version of ehcache (3.0). However, I can't seem to find what I want. I want to be able to set the eviction policy to LRU, however I can't seem to find any eviction policies in the docs. In the link they talk about the OddKeysEvictionAdvisor. If anyone can point me in the right direction it would be much appreciated.
http://www.ehcache.org/documentation/3.0/eviction-advisor.html
In Ehcache 3.0.x there is no configurable eviction policy.
The eviction advisor really is a way to hint that some cache mappings should be kept over others, and as the API shows, this does not include mapping metadata, only key and value.
We have been using EHCache with CF8 for a while now with no issues.
We are now moving to CF 9 and it seems that the baked-in version of EHCache with CF 9 is actually conflicting with our EHCache setup.
So is there:
Any way to disable the baked-in version of EHCache? This would be a temporary solution.
If we use the CF9 baked-in caching, is there any way to specify more than one cache in ehcache.xml and most importantly, to put into that specific cache via the tag?
Many thanks in advance.
Just create the CacheManager using the overloaded constructor which takes the path to your ehcache config file as an argument
http://ehcache.org/apidocs/net/sf/ehcache/CacheManager.html#CacheManager%28java.lang.String%29
This will create a non-singleton CacheManager which will play nice with CF9
Are they using the default classpath:ehcache.xml location? If so try seeing if you can initialize your CacheManager first then their code may end up just re-using your instance.