Another unnamed CacheManager already exists in the same VM (ehCache 2.5)

匿名 (未验证) 提交于 2019-12-03 02:13:02

问题:

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"

The ehcache.xml looks like

  ....  

Finally my class

@Component public class BookingCache implements CacheWrapper {       @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.

回答1:

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.



回答2:

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:

instead of using



回答3:

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.



回答4:

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.



回答5:

After upgrading to Hibernate 5 I had to use:

instead of:

Please not the different package.



回答6:

For posterity: A better way is to use the "accept-existing" property of the EhCacheManagerFactoryBean.



回答7:

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 :

 ${hibernate.dialect}falsefalsefalse

if i change to full configuration of second level cache config ,the real webapp use in running time,like this:

    ${hibernate.dialect}falsetruetruenet.sf.ehcache.hibernate.EhCacheRegionFactoryehcache/ehcache-hibernate-local.xml

then i get the same Exception "Another unnamed CacheManager already exists in the same VM"



回答8:

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; } 


回答9:

I solved it by adding following to resources.groovy :

beans = { ... aclCacheManager(EhCacheManagerFactoryBean) { shared = true } ... }



回答10:

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:

        org.hibernatehibernate-ehcache5.0.2.Finalnet.sf.ehcacheehcache2.7.4

To:

        org.hibernatehibernate-ehcache5.0.2.Final

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..



回答11:

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.(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.(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.



回答12:

In my case Problem is component-scan and java config.

root-context.xml   servlet-context.xml 

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   servlet-context.xml 


回答13:

This error also happens with wrong mapping files. The message is horrible, doesn't say the cause.



标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!