Подтвердить что ты не робот

Другой неназванный 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 ]

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

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

<ehcache:annotation-driven />

<bean
    id="cacheManager"
    class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
    scope="singleton"
    />

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

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
     updateCheck="false"
     maxBytesLocalHeap="100M" 
     name="cacheManager"
     >
 ....
 </ehcache>

Наконец, мой класс

@Component
public class BookingCache implements CacheWrapper<String, BookingUIBean> {

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

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

4b9b3361

Ответ 1

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

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

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

Сообщите factory bean создать общий экземпляр CacheManager в JVM, установив свойство shared в true,

<bean id="cacheManager"
      class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
      p:shared="true"/>

Ответ 2

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

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

вместо

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>

вместо:

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

Обратите внимание, что пакеты отличаются друг от друга.

Ответ 6

Для потомков: лучше всего использовать свойство "accept-существующие" EhCacheManagerFactoryBean.

Ответ 7

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

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

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

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

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

Ответ 8

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

Хитрость заключается в том, чтобы извлечь экземпляр кэша из bean, в этом кеше получить 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;
}

Ответ 9

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

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

Ответ 10

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

УДАЛИТЬ в application.yml

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

УДАЛИТЬ в pom.xml

<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
</dependency>

ПРОДОЛЖАЙТЕ только в pom.xml

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-ehcache</artifactId>
</dependency>

Ответ 11

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

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

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

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

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

Ответ 12

Настройка EhCacheManagerFactoryBean#shared на true сработала для меня.

Установка EhCacheManagerFactoryBean#acceptExisting на true НЕ работает для меня.

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

Как объяснено в Использование EhCache в Spring 4 без XML

Ответ 13

В glassfish 3.0.1 я проследил проблему с тем, что IniShiroFilter получает инициализацию дважды, что происходит, когда одновременные запросы запускаются сразу после запуска сервера. Ниже приведена трассировка стека из двух разных потоков, соответствующих двум запросам 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.<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)

Другой поток

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

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

Ответ 14

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

root-context.xml
<context:component-scan base-package="org.beansugar">

servlet-context.xml
<context:component-scan base-package="org.beansugar">

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

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

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>

Ответ 15

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

Ответ 16

В моем случае конфигурация была следующей:

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

Изменение класса провайдера EHCache сделало эту работу для меня. Я использовал класс провайдера кэша как org.hibernate.cache.EhCacheProvider, вместо этого я изменил это на: net.sf.ehcache.hibernate.SingletonEhCacheProvider

Ответ 17

Начиная с Spring Boot 2.1.2 для устранения проблемы использовалась следующая конфигурация. (Обратите внимание, это фрагменты общей конфигурации.)

Зависимости:

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

config.yml:

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:

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

Приложение, над которым я работаю, резко замедляется без рабочего кэша. Итак, для проверки я просто запустил приложение и нажал одну из интенсивно читаемых конечных точек.