Другой неназванный CacheManager уже существует в той же виртуальной машине (ehCache 2.5)

Это то, что происходит, когда я запускаю тесты junit …

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 ] 

В чем причина исключения. Может ли быть запущено более одного кэширования?

Вот как я настроил cachManager, используя Sping 3.1.1. Он явно устанавливает область действия cacheManager на «singleton»

   

Ehcache.xml выглядит так:

  ....  

Наконец мой class

 @Component public class BookingCache implements CacheWrapper { @Autowired private CacheManager ehCacheManager; .... } 

Я очень уверен, что я имею дело только с одним cacheManager в моей базе кода. Что-то еще, вероятно, запускает n-й экземпляр.

    Ваш EhCacheManagerFactoryBean может быть одиночным, но он создает несколько CacheManager и пытается дать им одно и то же имя. Это нарушает семантику Ehcache 2.5.

    Версии Ehcache до версии 2.5 позволяли использовать любое количество CacheManager с таким же именем (таким же ресурсом конфигурации) в JVM.

    Ehcache 2.5 и выше не позволяет нескольким CacheManager с тем же именем существовать в одной JVM. Конструкторы CacheManager (), создающие не-Singleton CacheManagers, могут нарушать это правило

    Сообщите фабричному компоненту создать общий экземпляр CacheManager в JVM, установив для общего свойства значение true.

      

    У меня была та же проблема с моими интеграционными тестами с использованием JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). Проблема была решена с использованием следующей конфигурации Hibernate:

      

    Вместо того, чтобы использовать

      

    Ваша проблема заключается в оптимизации загрузки контекста, созданной в тестовой среде Spring. Spring (по умолчанию) не уничтожает контекст после завершения тестового classа, в надежде, что другой тестовый class может его повторно использовать (вместо создания его с нуля).

    Вы можете переопределить это значение по умолчанию с помощью @DirtiesContext, или если вы используете maven, вы можете установить makefire forkMode на «всегда» и создать новую виртуальную машину для каждого тестового classа.

    Вы также можете попытаться установить имя «xxx» в вашей конфигурации ehcache.xml (в элементе ehcache).

    Это сделало трюк для меня, поскольку я думаю, что у меня была другая конфигурация кэша, скрывающаяся в одном из модhive моего приложения.

    Совместное решение также работает, но я не знаю далеко идущих последствий этого.

    После перехода на Hibernate 5 мне пришлось использовать:

      

    вместо:

      

    Пожалуйста, не другой пакет.

    Для потомков: лучший способ – использовать свойство accept-existing для EhCacheManagerFactoryBean .

    если вы просто протестируете свой бизнес-сервис, а не кеш второго уровня, вы можете удалить конфигурацию второго уровня в своем конфигурационном файле весны, ваш тест будет успешно выполнен. есть моя конфигурация второго уровня:

            ${hibernate.dialect} false  false false    

    если я перейду на полную конфигурацию конфигурации кэша второго уровня, реальный webapp будет использоваться во время работы, например:

            ${hibernate.dialect} false  true true net.sf.ehcache.hibernate.EhCacheRegionFactory ehcache/ehcache-hibernate-local.xml    

    то я получаю то же исключение «Еще один неназванный CacheManager уже существует в той же виртуальной машине»

    В моем случае у нас есть пользовательский менеджер кэша, определенный как bean-компонент. Также настраиваемый контекст приложения, поэтому мы не используем Spring junit runner … поэтому @DirtiesContext не работает.

    Хитрость заключается в том, чтобы извлечь экземпляр кэша из компонента, в этом кеше получить cacheManager (экземпляр из EHCache). и на этом кешменеджере вызывается метод removeCache.

    Поместите это в метод, аннотированный с @After, и ваш кеш удаляется из виртуальной машины после каждого теста. Как это:

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

    Я решил это, добавив следующее к ресурсам.groovy:

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

    Это случилось со мной при переключении на Spring Boot 2.0.2 . Решил его, выполнив следующие действия:

    УДАЛИТЬ в application.yml

     spring.jpa.properties.hibernate.cache.region.factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory 

    УДАЛИТЬ в pom.xml

      net.sf.ehcache ehcache  

    ХРАНИТЬ только в pom.xml

      org.hibernate hibernate-ehcache  

    Для будущих читателей причиной этой проблемы в моем случае было то, что в моем файле pom.xml я импортировал библиотеку hibernate-ehcache, которая мне неизвестна, также уже содержала библиотеку ehcache, а затем явно импортировала net.sf.ehache libray.

    Это, казалось, отлично работало, когда я работал как автономное приложение (например, служебная программа командной строки), но это вызвало ошибку в исходном сообщении при работе на сервере tomcat.

    Изменение моего файла pom:

       org.hibernate hibernate-ehcache 5.0.2.Final   net.sf.ehcache ehcache 2.7.4  

    Для того, чтобы:

       org.hibernate hibernate-ehcache 5.0.2.Final   

    Исправлена ​​проблема. Если кто-нибудь знает, почему проблема появилась только при запуске в контейнере tomcat, мне было бы интересно узнать ..

    В glassfish 3.0.1 я проследил проблему с тем, что IniShiroFilter получает инициализацию дважды, что происходит, когда одновременные запросы запускаются сразу после запуска сервера. Ниже приведена трассировка стека из двух разных streamов, соответствующих двум запросам HTTP:

     [#|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) 

    Еще одна тема

     [#|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) 

    Глядя на трассировку стека, ApplicationFilterConfig.java:248 может быть виновником. Или, Glassfish инициализирует фильтры в неправильном контексте, для сравнения Tomcat инициализирует фильтры во время BootStrap.

    В моем случае проблема – это компонент-сканирование и java-конфиг.

     root-context.xml  servlet-context.xml  

    Функция весеннего компонента-сканирования работает два раза в файлах xml. он генерирует бобы внутри SpringConfig.java для каждого времени выполнения. затем был создан дублирующий менеджер кэша.

    поэтому я изменил это, как показано ниже.

     root-context.xml    servlet-context.xml    

    Эта ошибка также возникает при неправильных файлах сопоставления. Сообщение ужасно, не говорит о причине.

    Давайте будем гением компьютера.