Otro CacheManager sin nombre ya existe en la misma VM (ehCache 2.5)

76

Esto es lo que sucede cuando ejecuto mis pruebas 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 ]

Cuál es la razón detrás de la excepción. ¿Podría haber más de 1 cacheManager ejecutándose simultáneamente?

Así es como configuré cachManager usando Sping 3.1.1. Establece explícitamente el alcance del cacheManager en "singleton"

<ehcache:annotation-driven />

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

El ehcache.xml se parece a

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

Finalmente mi clase 

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

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

Estoy muy seguro de que estoy tratando con un solo cacheManager en mi base de código. Algo más probablemente esté ejecutando la enésima instancia.

spring junit ehcache simou
fuente
4
He visto el mismo problema con ehCache 2.5 o superior. Usar 2.4.7 no causa este problema, pero sería bueno saber cómo hacer que 2.5 sea compatible con junit.
aweigold
1
Gracias. Cambié de nuevo a 2.4.7 que está bien por ahora. También hay una entrada de blog que analiza posibles soluciones (aunque ninguna de ellas parece ser muy atractiva) norrisshelton.wordpress.com/2012/03/08/…
simou
La solución de Norris Shelton funciona para mí ( norrisshelton.wordpress.com/2012/03/08/… )
jbbarquero
Esta solución no parece funcionar para mí, aunque estoy usando testNG. Sigo recibiendo "Otro CacheManager con el mismo nombre 'myCacheManager' ya existe en la misma máquina virtual" :(
nodje
Creo que [aquí] [1] también resuelve el problema. [1]: stackoverflow.com/questions/11139653/…
Lekkie

Respuestas:

46

Su EhCacheManagerFactoryBean puede ser un singleton, pero está construyendo múltiples CacheManagers e intentando darles el mismo nombre. Eso viola la semántica de Ehcache 2.5 .

Las versiones de Ehcache anteriores a la versión 2.5 permitían que existiera cualquier número de CacheManagers con el mismo nombre (mismo recurso de configuración) en una JVM.

Ehcache 2.5 y superior no permite que existan varios CacheManagers con el mismo nombre en la misma JVM. Los constructores de CacheManager () que crean CacheManagers que no son Singleton pueden violar esta regla

Dígale al bean de fábrica que cree una instancia compartida de CacheManager en la JVM estableciendo la propiedad compartida en true.

<bean id="cacheManager"
      class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
      p:shared="true"/>
Emerson Farrugia
fuente
5
Una cosa a tener en cuenta, si Spring está procesando automáticamente el EhCacheManagerFatoryBean, es posible que aún obtenga el error incluso si establece p: shared en verdadero. La forma de evitar esto es no usar el nombre predeterminado para su archivo, en lugar de usar ehcache.xml cambie el nombre del archivo y agregue p: config-location a su declaración EhCacheManagerFactoryBean con el nuevo nombre de archivo.
TechTrip
1
@TechTrip: He hecho exactamente eso: tengo p:config-location="classpath:ehcache-foo.xml" p:shared="true"mi EhCacheManagerFactoryBean y, sin embargo, tengo un conflicto porque dos WAR en mi JVM usan este mismo módulo.
mcv
3
Corríjame si me equivoco, pero ¿no significa esto que una segunda prueba reutilizará el caché de la primera prueba con los datos almacenados en caché todavía? Esto podría provocar un comportamiento difícil de depurar porque la segunda prueba no se inicia en un estado conocido. El resultado de la prueba puede depender del orden de la prueba. (Por supuesto, las pruebas de caja negra no deberían depender de si se usa o no una caché, pero es perfectamente válido tener pruebas de rendimiento que dependan del estado de la caché o tal vez esté probando su propia utilidad de almacenamiento en caché que usa ehcache bajo las cubiertas)
Henno Vermeulen
42

Tuve el mismo problema con mis pruebas de integración usando JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). El problema se resolvió utilizando la siguiente configuración de Hibernate:

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

En lugar de usar 

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
Felix Reckers
fuente
3
Adapté esta solución para solucionar mis problemas de prueba de Spring Boot: utilicé org.hibernate.cache.ehcache.EhCacheRegionFactory en lugar de net.sf.ehcache.hibernate.EhCacheRegionFactory para Hibernate 4 . Con Spring Boot puedes configurar esto en application.properties: spring.jpa.properties.hibernate.cache.region.factory_class = org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory o con @TestPropertySource si quieres limitar la configuración a la prueba.
Michael Koch
1
Vaya, me salvé el día después de actualizar de hibernate 4.3.xa 5.2.
smallufo
22

Su problema es la optimización de la carga de contexto construida en el marco de prueba Spring. Spring (por defecto) no destruye el contexto una vez que finaliza la clase de prueba, con la esperanza de que otra clase de prueba pueda reutilizarlo (en lugar de crearlo desde cero).

Puede anular este valor predeterminado usando @DirtiesContext, o si usa maven, puede configurar surefire forkMode en "always" y crear una nueva VM por clase de prueba.

Dejan P
fuente
3
Esto resuelve el problema de forma limpia para entornos de prueba sin cambiar la configuración de tiempo de ejecución real. ¡Agradable!
perdió el
2
forkmode = always es un buen grito pero está en desuso. ver: maven.apache.org/surefire/maven-surefire-plugin/examples/… TRY forkCount = 1 (predeterminado), reuseForks = false
theINtoy
12

También puede intentar establecer el nombre "xxx" en su configuración ehcache.xml (en el elemento ehcache).

Eso funcionó para mí, ya que creo que tenía otra configuración de caché al acecho en uno de los módulos de mi aplicación.

La solución compartida también funciona, pero no conozco las implicaciones de largo alcance de eso.

Michael Holst
fuente
¡Si! Esa resultó ser la única solución para mí. Añadiendo el atributo de nombre al elemento echache superior. Eso no parece estar documentado en el archivo ehcache.xml de ejemplo ..
Nicolas Mommaerts
Demasiado triste que leí solo la primera respuesta aquí, después de eso, vuelvo a eclipse leyendo toda la fuente de inicio de spring & ehcache para descubrir que se necesita el atributo de nombre, de lo contrario, se ignora el archivo de configuración ...
jpprade
buena solución, obtuve la misma excepción con dos pruebas unitarias en dos módulos diferentes que ambos usaban ehcache, cada uno con su propio archivo y esto resuelve el problema
Henno Vermeulen
Excelente. Pero todavía no puedo entender cómo se puede resolver el problema poniendo el nombre a ehcache.xml. Estoy usando el caché de primavera + caché de segundo nivel de hibernación. Ambos usan el mismo ehcache.xml.
santu
1
Esta solución solo funciona con configuraciones en conflicto (varios archivos ehcache.xml), si usa solo uno, entonces podría ser otro problema.
Michael Holst
12

Después de actualizar a Hibernate 5 tuve que usar:

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

en vez de:

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

Tenga en cuenta que los paquetes son diferentes entre sí.

ojos
fuente
2

Si solo prueba su servicio comercial, no el caché de segundo nivel, puede eliminar la configuración de segundo nivel en su archivo de configuración de primavera, su prueba se ejecutará correctamente. hay mi configuración de segundo nivel:

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

si cambio a la configuración completa de la configuración de caché de segundo nivel, el uso real de la aplicación web en tiempo de ejecución, así:

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

luego obtengo la misma excepción "Otro CacheManager sin nombre ya existe en la misma VM"

roger.li
fuente
2

En mi caso, tenemos un administrador de caché personalizado definido como bean. También un contexto de aplicación personalizado para que no usemos el corredor Spring Junit ... por lo tanto, @DirtiesContext no funciona.

El truco consiste en recuperar la instancia de caché del bean, en esa caché obtenga el cacheManager (la instancia de EHCache). y en ese cachemanager llame al método removeCache.

Coloque esto en un método anotado con @After y su caché se eliminará de la VM después de cada prueba. Me gusta esto:

@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;
}
Pim Hazebroek
fuente
2

Lo resolví agregando lo siguiente a resources.groovy:

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

Dasma
fuente
2

Me pasó al cambiar a Spring Boot 2.0.2 . Lo resolvió haciendo lo siguiente:

ELIMINAR en application.yml

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

ELIMINAR en pom.xml

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

MANTENER solo en pom.xml

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-ehcache</artifactId>
</dependency>
Ronny Shibley
fuente
2

Configurar el EhCacheManagerFactoryBean#shareda truefuncionó para mí.

Configurar el EhCacheManagerFactoryBean#acceptExistingen trueNO funcionó para mí.

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

Como se explica en Uso de EhCache en Spring 4 sin XML

Compañero Šimović
fuente
1

Para los futuros lectores, la causa de este problema en mi caso fue que en mi archivo pom.xml había importado la biblioteca hibernate-ehcache, que desconocía para mí también ya contenía la biblioteca ehcache, y luego importé explícitamente el net.sf.ehache libray.

Esto parecía funcionar bien cuando me estaba ejecutando como una aplicación independiente (una utilidad de línea de comando, por ejemplo) pero causó el error en la publicación original cuando se ejecutaba en un servidor Tomcat.

Cambiando mi archivo pom de:

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

A:

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-ehcache</artifactId>
            <version>5.0.2.Final</version>
        </dependency>
        <!-- ehcache dependency removed -->

Solucionado el problema. Si alguien tiene alguna idea de por qué el problema solo apareció cuando se ejecuta en un contenedor Tomcat, me interesaría saberlo.

Matt Watson
fuente
0

En glassfish 3.0.1, rastreé el problema hasta que IniShiroFilter se inicializaba dos veces, lo que sucede cuando se activan solicitudes simultáneas justo después del inicio del servidor. A continuación, se muestra un seguimiento de la pila de dos subprocesos diferentes correspondientes a dos solicitudes 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)

Otro hilo 

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

Observar el seguimiento de la pila ApplicationFilterConfig.java:248 podría ser el culpable. O, glassfish está inicializando filtros en el contexto incorrecto, a modo de comparación, Tomcat inicializa filtros durante BootStrap.

jsh
fuente
0

En mi caso, el problema es el escaneo de componentes y la configuración de java.

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

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

Spring Component-Scan funciona dos veces en archivos xml. genera beans dentro de SpringConfig.java cada vez que se ejecuta. luego se creó el administrador de caché duplicado.

así que cambié eso como a continuación.

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>
archimago
fuente
0

Este error también ocurre con archivos de mapeo incorrectos. El mensaje es horrible, no dice la causa.

ejaenv
fuente
0

En mi caso, la configuración fue la siguiente:

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

Cambiar la clase de proveedor de EHCache hizo el trabajo por mí. Estaba usando la clase de proveedor de caché, ya que en su org.hibernate.cache.EhCacheProviderlugar cambié esto a: net.sf.ehcache.hibernate.SingletonEhCacheProvider

Ritesh
fuente
0

A partir de Spring Boot 2.1.2, la siguiente configuración funcionó para resolver el problema. (Tenga en cuenta que estos son fragmentos de la configuración general).

Dependencias:

<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

Configuración de 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>

La aplicación en la que estoy trabajando se ralentiza drásticamente sin un caché que funcione. Entonces, para validar, simplemente ejecuté la aplicación y golpeé uno de los puntos finales de lectura intensa.

virtualadrian
fuente