Another unnamed CacheManager already exists in the same VM (ehCache 2.5)
SpringJunitEhcacheSpring Problem Overview
This is what happens when I run my junit tests...
Another CacheManager with same name 'cacheManager' already exists in the same VM. Please
provide unique names for each CacheManager in the config or do one of following:
1. Use one of the CacheManager.create() static factory methods to reuse same
CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.
The source of the existing CacheManager is:
DefaultConfigurationSource [ ehcache.xml or ehcache-failsafe.xml ]
What's the reason behind the exception. Could there be more than 1 cacheManager running simultaneously?
This is how I configured the cachManager using Sping 3.1.1. It sets explicitly the scope of the cacheManager to "singleton"
<ehcache:annotation-driven />
<bean
id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
scope="singleton"
/>
The ehcache.xml looks like
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="false"
maxBytesLocalHeap="100M"
name="cacheManager"
>
....
</ehcache>
Finally my class
@Component
public class BookingCache implements CacheWrapper<String, BookingUIBean> {
@Autowired
private CacheManager ehCacheManager;
....
}
I'm very sure that I'm dealing with only one cacheManager in my code base. Something else is probably running the n-th instance.
Spring Solutions
Solution 1 - Spring
Your EhCacheManagerFactoryBean may be a singleton, but it's building multiple CacheManagers and trying to give them the same name. That violates Ehcache 2.5 semantics.
> Versions of Ehcache before version 2.5 allowed any number of CacheManagers with the same name (same configuration resource) to exist in a JVM. > > Ehcache 2.5 and higher does not allow multiple CacheManagers with the same name to exist in the same JVM. CacheManager() constructors creating non-Singleton CacheManagers can violate this rule
Tell the factory bean to created a shared instance of the CacheManager in the JVM by setting the shared property to true.
<bean id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
p:shared="true"/>
Solution 2 - Spring
I had the same issue with my integration tests using JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). The issue was resolved using following Hibernate configuration:
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
instead of using
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
Solution 3 - Spring
Your problem is the context loading optimization built in the Spring test framework. Spring (per default) does not destroy the context once the test class is done, in hope that another test class might reuse it (instead of creating it from scratch).
You can override this default using @DirtiesContext, or if you use maven you can set surefire forkMode to "always" and create a new VM per test class.
Solution 4 - Spring
After upgrading to Hibernate 5 I had to use:
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>
instead of:
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
Please note that the packages differ from each other.
Solution 5 - Spring
You may also try to set name"xxx" on your ehcache.xml configuration (on the ehcache element).
That did the trick for me, as I think I had another cache configuration lurking in one of the modules of my app.
The shared solution also works, but I don't know the far-ranging implications of that.
Solution 6 - Spring
For posterity: A better way is to use the "accept-existing" property of the EhCacheManagerFactoryBean.
Solution 7 - Spring
if you just test your business service,not second level cache,you can remove second level configuration in your spring config file,your test will be run successfully. there is my second level configuration :
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceUnitName" value="defaultPU" />
<property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">false</prop>
<!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
<prop key="hibernate.cache.use_second_level_cache">false</prop>
<prop key="hibernate.cache.use_query_cache">false</prop>
</props>
</property>
</bean>
if i change to full configuration of second level cache config ,the real webapp use in running time,like this:
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceUnitName" value="defaultPU" />
<property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">false</prop>
<!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
<prop key="hibernate.cache.use_second_level_cache">true</prop>
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</prop>
<prop key="net.sf.ehcache.configurationResourceName">ehcache/ehcache-hibernate-local.xml</prop>
</props>
</property>
</bean>
then i get the same Exception "Another unnamed CacheManager already exists in the same VM"
Solution 8 - Spring
In my case, we have a custom cache manager defined as bean. Also a custom application context so we don't use the spring junit runner... hence the @DirtiesContext doesn't work.
The trick is to retrieve the cache instance from the bean, on that cache get the cacheManager (the instance from EHCache). and on that cachemanager call the removeCache method.
Put this in a method annotated with @After and your cache is removed from the VM after each test. Like this:
@After
public void destroy() {
MyCustomCacheManager customCacheManager = (MyCustomCacheManager) context.getBean("yourCustomCacheManagerBean");
try {
net.sf.ehcache.Cache cache = customCacheManager.getCache();
net.sf.ehcache.CacheManager cacheManager = cache.getCacheManager();
cacheManager.removeCache("nameOfYourCache");
} catch (IllegalAccessException e) {
e.printStackTrace();
}
context.destroy();
context = null;
}
Solution 9 - Spring
I solved it by adding following to resources.groovy :
beans = { ... aclCacheManager(EhCacheManagerFactoryBean) { shared = true } ... }
Solution 10 - Spring
It happened to me when switching to Spring Boot 2.0.2. Resolved it by doing the following:
REMOVE in application.yml
spring.jpa.properties.hibernate.cache.region.factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory
REMOVE in pom.xml
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
</dependency>
KEEP in pom.xml only
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
</dependency>
Solution 11 - Spring
Setting the EhCacheManagerFactoryBean#shared to true worked for me.
Setting the EhCacheManagerFactoryBean#acceptExisting to true DIDN'T work for me.
import org.springframework.cache.ehcache.EhCacheCacheManager;
import org.springframework.cache.ehcache.EhCacheManagerFactoryBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.ClassPathResource;
@Configuration
public class EhCacheConfiguration {
@Bean
public EhCacheCacheManager ehCacheCacheManager() {
return new EhCacheCacheManager(ehCacheManagerFactoryBean().getObject());
}
@Bean
public EhCacheManagerFactoryBean ehCacheManagerFactoryBean() {
EhCacheManagerFactoryBean cacheManagerFactoryBean = new EhCacheManagerFactoryBean();
cacheManagerFactoryBean.setConfigLocation(new ClassPathResource("ehcache.xml"));
cacheManagerFactoryBean.setShared(true);
return cacheManagerFactoryBean;
}
}
As explained in Using EhCache in Spring 4 without XML
Solution 12 - Spring
For future readers, the cause of this problem in my case was that in my pom.xml file I had imported the hibernate-ehcache library, which unknown to me also already contained the ehcache library, and then explicitly imported the net.sf.ehache libray.
This seemed to work fine when I was running as a standalone app (a command line utility for example) but it caused the error in the original post when running on a tomcat server.
Changing my pom file from:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.0.2.Final</version>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>2.7.4</version>
</dependency>
To:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.0.2.Final</version>
</dependency>
<!-- ehcache dependency removed -->
Fixed the problem. If anyone has any idea why the problem only appeared when running in a tomcat container I'd be interested to know..
Solution 13 - Spring
In glassfish 3.0.1, I traced the issue to IniShiroFilter getting initialize twice, which happens when concurrent requests are fired just after the server start. Following is a stack trace from two different threads corresponding to two HTTP requets:
[#|2012-11-28T08:25:10.630-0800|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=28;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1249)
at org.apache.shiro.web.servlet.IniShiroFilter.<init>(IniShiroFilter.java:124)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:303)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:725)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1948)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:248)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sentilla.filter.DumpFilter.doFilter(DumpFilter.java:152)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:662)
Another thread
[#|2012-11-28T08:25:15.299-0800|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1249)
at org.apache.shiro.web.servlet.IniShiroFilter.<init>(IniShiroFilter.java:124)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:303)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:725)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1948)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:248)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sentilla.filter.DumpFilter.doFilter(DumpFilter.java:152)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:662)
Looking at the stack trace ApplicationFilterConfig.java:248 could be the culprit. Or, glassfish is initializing filters in the wrong context, for comparison, Tomcat initializes filters during BootStrap.
Solution 14 - Spring
In my case Problem is component-scan and java config.
root-context.xml
<context:component-scan base-package="org.beansugar">
servlet-context.xml
<context:component-scan base-package="org.beansugar">
spring component-scan work two times on xml files. it generate beans inside SpringConfig.java each run time. then duplicate cache manager was created.
so, I changed that like below.
root-context.xml
<context:component-scan base-package="org.beansugar">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
servlet-context.xml
<context:component-scan base-package="org.beansugar" use-default-filters="false">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
Solution 15 - Spring
This error also happens with wrong mapping files. The message is horrible, doesn't say the cause.
Solution 16 - Spring
In my case configuration was as follows:
<spring.boot.version>1.5.8.RELEASE</spring.boot.version>
<spring.boot.yarn.version>2.4.0.RELEASE</spring.boot.yarn.version>
<spring.version>4.3.7.RELEASE</spring.version>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.5.1-Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>3.5.1-Final</version>
</dependency>
Changing the EHCache provider class did the job for me. I was using cache provider class as
Solution 17 - Spring
As of Spring Boot 2.1.2 the following configuration worked to resolve the issue. (Note, these are snippets of the overall config.)
Dependencies:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.2.8.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.2.8.Final</version>
</dependency>
application.yml config:
spring:
jpa:
open-in-view: false
hibernate:
ddl-auto: none
show-sql: true
properties:
dialect: org.hibernate.dialect.MySQLDialect
net:
sf:
ehcache:
configurationResourceName: ehcache.xml
hibernate:
cache:
use_second_level_cache: true
region:
factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory
ehcache.xml configuration:
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<!-- Required elements -->
<diskStore path="java.io.tmpdir"/>
<defaultCache
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="true"/>
<!-- Cache settings per class -->
<cache name="com.mystuff.component.services.example.Book"
maxElementsInMemory="1000"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
overflowToDisk="true"/>
</ehcache>
The application I am working on slows down drastically without a working cache. So, to validate I simply ran the application and hit one of the read intense endpoints.
Solution 18 - Spring
In my case the Manager was created by this bean (ehCache 2.10):
<bean id="ehcache"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="shared" value="false"/>
</bean>
the only solution that worked for me is to destroy it manually in that way :
@Inject
private EhCacheManagerFactoryBean ehCacheManagerFactoryBean;
And then
ehCacheManagerFactoryBean.destroy();