I have this Ehcache XML configuration:
<ehcache>
<defaultCache
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="false"
diskSpoolBufferSizeMB="30"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="120"
memoryStoreEvictionPolicy="LRU"
/>
</ehcache>
And also, I have some packages with entities (around 150). If I deploy my application on tomcat server, there is a lot WARN messages in log:
2015-04-29 11:59:02,712 [RMI TCP Connection(3)-127.0.0.1] WARN
org.hibernate.cache.ehcache.AbstractEhcacheRegionFactory - HHH020003:
Could not find a specific ehcache configuration for cache named
[com.company.project.entity.package.MyEntity]; using defaults.
I can write configuration for each entity -
<cache name="com.company.project.entity.package.MyEntity"
maxEntriesLocalHeap="50"
eternal="false"
overflowToDisk="false"
timeToLiveSeconds="120">
<persistence strategy="localTempSwap"/>
</cache>
But in this way, my configuration file become too large (1600 rows). I think there is exist another way to set default config to each entity and kill warn messages, but I don't know how to do it. If anybody know, please help. Many thanks.
This is the Hibernate EHCache Cache Region code that logs the warning message:
private Ehcache getCache(String name) throws CacheException {
try {
Ehcache cache = manager.getEhcache( name );
if ( cache == null ) {
LOG.unableToFindEhCacheConfiguration( name );
manager.addCache( name );
cache = manager.getEhcache( name );
LOG.debug( "started EHCache region: " + name );
}
HibernateEhcacheUtils.validateEhcache( cache );
return cache;
}
catch (net.sf.ehcache.CacheException e) {
throw new CacheException( e );
}
}
As you can see, you have two options:
You either declare the cache region in the ehcache.xml file.
You set the 'org.hibernate.cache.ehcache.AbstractEhcacheRegionFactory' log level to ERROR:
For Log4j2:
<Logger name="org.hibernate.cache.ehcache.AbstractEhcacheRegionFactory" level="error">
<AppenderRef ref="File"/>
</Logger>
One option would be to create a CacheObject base entity and configure that as your cache object.
Not the cleanest of solution but would remove the warnings without adding a large amount of config.
As the warning is just that, a warning personally i would just configure it to not show.
Related
Below is ehcache configuration we are using. We use Jgroups for cache replication.
ehcache.xml
<defaultCache
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="1200"
timeToLiveSeconds="86400"
overflowToDisk="true"
diskSpoolBufferSizeMB="30"
maxElementsOnDisk="10000000"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="120"
memoryStoreEvictionPolicy="LRU">
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheReplicatorFactory"
properties="replicateAsynchronously=true,replicatePuts=true,replicateUpdates=true,replicateUpdatesViaCopy=true,replicateRemovals=true" />
</defaultCache>
jgroups_tcp_config.xml
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.0.xsd">
<!--Configure node ip inside bind_addr-->
<TCP bind_addr="host1" bind_port="7831" max_bundle_size="9999999"/>
<!--Configure nodes inside 'initial_hosts' property-->
<TCPPING timeout="3000" initial_hosts="host1[7831],host2[7831]" port_range="1" num_initial_members="3"/>
<FRAG2 frag_size="9999999"/>
<MERGE3 max_interval="30000" min_interval="10000"/>
<FD timeout="3000" max_tries="10"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK use_mcast_xmit="false" exponential_backoff="500" discard_delivered_msgs="false"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="5000" view_bundling="true"/>
</config>
Initially from the logs we can see that the nodes are getting clustered. Also we can see that messages are being replicated across nodes. But after some time, we see that messages are no more being replicated and hence resulting in erroneous behavior. Is there any problem with the jgroups configurations we are using?
Also we tried using NAKACK2, but the messages are not getting replicated across nodes at all. We simply replaced NAKACK with NAKACK2 in above configuration specified. Not sure where we are going wrong.
Above issue we are facing in AWS cloud.Ehcache Jgroups tcp will not work in cloud environment because cloud VPN dosn't support TCP multicasting due to which node discovery will not happen, to address this we are using jgroups_s3_config.xml instead of jgroups_tcp_config.xml in the AWS cloud.With the following jgroups_s3_config.xml configuration we have addressed the issue.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.1.xsd">
<TCP loopback="true" bind_port="7800"/>
<S3_PING location="s3 bucket name should be in the same region in which app servers are running"
access_key="s3 bucket access key from aws credential file"
secret_access_key="s3 bucket secret access key from aws credential file" timeout="10000" num_initial_members="2"/>
<FRAG2/>
<MERGE2 min_interval="10000" max_interval="30000"/>
<FD_ALL timeout="12000" interval="3000" timeout_check_interval="4000"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="false"/>
<UNICAST2 timeout="300,600,1200"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="40K"/>
<pbcast.GMS print_local_addr="true" join_timeout="5000" view_bundling="true"/>
</config>
Additionally we have to set the JAVA_OPTS.
export JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"
Why the following ehcache.xml doesn't allow to clear caches via JMX (the Operations tab is disabled in JVisualVM for MBean for cache management and enabled for cache statistic)? I use spring boot framework and specify ehcache.xml file location via spring.cache.jcache.config property and just use #Cachable spring framework annotation.
<config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://www.ehcache.org/v3'
xmlns:jsr107='http://www.ehcache.org/v3/jsr107'
xsi:schemaLocation="
http://www.ehcache.org/v3 http://www.ehcache.org/schema/ehcache-core-3.0.xsd
http://www.ehcache.org/v3/jsr107 http://www.ehcache.org/schema/ehcache-107-ext-3.0.xsd">
<service>
<jsr107:defaults enable-management="true" enable-statistics="true"/>
</service>
<cache alias="stringCache">
<key-type>java.lang.String</key-type>
<value-type>java.lang.String</value-type>
<heap unit="entries">2000</heap>
</cache>
</config>
Clearing cache entries is not supported by the JSR-107 specification. Only clearing the statistics is possible. To workaround that, you will have to create your own MBean.
I have configured ehcache for hibernate 2nd level cache to use a Terracotta server. Everything is working fine, except the UpdateTimestampsCache for the query cache is just not showing up in the Dev Console. We are using Hibernate 3.6.10 and ehcache 2.6.0.
I am seeing all entity, collection, query and the StandardQueryCache, but not org.hibernate.cache.UpdateTimestampsCache. I know the timestamp cache exists and is being used because I can see the stats on it using the the metrics lib instrumented in.
Any ideas?
Thanks!
Here's my ehcache.xml config
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="false"
name="Hibernate-CacheManager"
monitoring="autodetect"
dynamicConfig="true">
<terracottaConfig url="localhost:9510" />
<defaultCache
eternal="false"
overflowToDisk="false"
maxElementsInMemory="50000"
timeToIdleSeconds="7200"
timeToLiveSeconds="0">
<cacheDecoratorFactory
class="com.yammer.metrics.ehcache.InstrumentedEhcacheFactory" />
<terracotta/>
</defaultCache>
<cache
name="org.hibernate.cache.UpdateTimestampsCache"
eternal="false"
overflowToDisk="false"
maxElementsInMemory="500"
timeToIdleSeconds="7200"
timeToLiveSeconds="0">
<cacheDecoratorFactory
class="com.yammer.metrics.ehcache.InstrumentedEhcacheFactory" />
<terracotta/>
</cache>
<cache
name="org.hibernate.cache.StandardQueryCache"
eternal="false"
overflowToDisk="false"
maxElementsInMemory="50000"
timeToIdleSeconds="7200"
timeToLiveSeconds="0">
<cacheDecoratorFactory
class="com.yammer.metrics.ehcache.InstrumentedEhcacheFactory" />
<terracotta/>
</cache>
</ehcache>
Recopying answer from: http://forums.terracotta.org/forums/posts/list/0/7554.page#36815
Hibernate does not maintain statistics for the UpdateTimestampsCache cache up to Hibernate 4.0.0. This explains why the cache does not show up in the terracotta dev console.
This is filed as bug https://hibernate.onjira.com/browse/HHH-5326
I'm trying to move the creation of Cache that uses RMI from ehcache.xml file to a Spring xml.
It wasn't a problem to just create a EhCacheFactoryBean but how does RMICacheReplicatorFactory definition suppose to/can be implemented?
Here is how it looks in ehcache.xml file.
Many thanks,
Idan
<cache name="MyCache1"
maxElementsInMemory="1000"
eternal="false"
overflowToDisk="true"
diskSpoolBufferSizeMB="20"
timeToLiveSeconds="3000"
timeToIdleSeconds="3000"
memoryStoreEvictionPolicy="LFU">
<!-- RMI replication listener -->
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicateAsynchronously=true,
replicatePuts=true,
replicatePutsViaCopy=true,
replicateUpdates=true,
replicateUpdatesViaCopy=true,
replicateRemovals=true" />
<!-- RMI Cache bootstrap -->
<bootstrapCacheLoaderFactory
class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory"
properties="bootstrapAsynchronously=true, maximumChunkSizeBytes=5000000"
propertySeparator="," />
</cache>
When using Spring 3 there is a cacheEventListeners property of type Set<CacheEventListener> for the EhCacheFactoryBean (see https://jira.springsource.org/browse/SPR-6234). When using 2.5 you could extend EhCacheFactoryBean yourself like shown here.
I want to distribute my EhCache via a JMS Topic. This is documented here on EhCache's site
I'm using:
ehcache-1.6.0-beta3
ehcache-jmsreplication-0.3
spring-2.5
spring-modules-0.9
My Spring config looks like this:
<bean id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
</bean>
<bean id="cacheProvider"
class="org.springmodules.cache.provider.ehcache.EhCacheFacade">
<property name="cacheManager" ref="cacheManager" />
</bean>
<ehcache:proxy id="pocDaoCache" refId="pocDao">
<ehcache:caching methodName="fetch" cacheName="pocCache" />
</ehcache:proxy>
And, pre-JMS config, my ehcache.xml looks like this:
<diskStore path="c:/projects/cache/demo" />
<defaultCache maxElementsInMemory="50" eternal="false"
timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true" />
<cache name="pocCache"
maxElementsInMemory="10000"
maxElementsOnDisk="1000"
eternal="false"
overflowToDisk="true"
diskSpoolBufferSizeMB="20"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
memoryStoreEvictionPolicy="LFU"
/ >
And this works fine. So I add my Topic information:
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.jms.JMSCacheManagerPeerProviderFactory"
properties="initialContextFactoryName=JmsInitialContextFactory,
userName=myuser,password=mypass,
providerURL=tcp://jmsdev1-jndi,tcp://jmsdev2-jndi
topicConnectionFactoryBindingName=TCF-00,
topicBindingName=MyTopiceName"
propertySeparator=","
/>
And I get a NullPointer when I get an application context. Here is the stack trace:
org.springframework.beans.factory.BeanCreationException:
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'cacheManager' defined in class path resource [cache-context.xml]:
Invocation of init method failed; nested exception is java.lang.NullPointerException
at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.initializeBean(AbstractAutowireCapableBeanFactory.java:1336)
at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.doCreateBean(AbstractAutowireCapableBeanFactory.java:471)
at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getOb
ject(AbstractBeanFactory.java:264)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistr
y.getSingleton(DefaultSingletonBeanRegistry.java:217)
[snip]
Any ideas from anyone?
The real problem is that Ehcache's documentation isn't right -- not even close -- to how it is really implemented. Through logging and looking through the code in the jmsreplication module, I was able to get it working.
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.jms.JMSCacheManagerPeerProviderFactory"
properties="initialContextFactoryName=com.InitialContextFactory;
userName=uname;password=passwd;
replicationTopicConnectionFactoryBindingName=TCF;
replicationTopicBindingName=CACHE;
providerURL=tcp://server1:7222,tcp://server2:7222;
getQueueConnectionFactoryBindingName=QCF;
getQueueBindingName=CACHE_LOAD
"
propertySeparator=";"
/>
Another thing that tripped me up was simple, once I realized it -- you have to implement your own key generator to ensure that Ehcache saves the objects with the same keys on each JVM. That makes perfect sense, when you think about it.
Yes, you have to put in the loader queue information into the cacheManagerPeerProviderFactory. That is because, if you start up a process after one has been running, the new process can pre-load the cache from the existing process.
You configure the loader requester (cacheLoaderFactory) with the exact same settings:
<cacheLoaderFactory
class="net.sf.ehcache.distribution.jms.JMSCacheLoaderFactory"
properties="initialContextFactoryName=com.InitialContextFactory;
userName=uname;password=passwd;
replicationTopicConnectionFactoryBindingName=TCF;
replicationTopicBindingName=CACHE;
providerURL=tcp://server1:7222,tcp://server2:7222;
getQueueConnectionFactoryBindingName=QCF;
getQueueBindingName=CACHE_LOAD
"
propertySeparator=";"
/>
Regarding the key generation issue, it's actually a known problem - MOD-255. We are going to be patching that into the Spring Modules Fork shortly.