example - org springframework cache ehcache

Otro CacheManager sin nombre ya existe en la misma máquina virtual(ehCache 2.5)

Question

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é el cachManager usando Sping 3.1.1. Establece explícitamente el alcance de cacheManager para "singleton"

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

El ehcache.xml parece

<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 solo un cacheManager en mi base de código. Algo más probablemente esté ejecutando la enésima instancia.

Answer 1

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

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

en lugar de:

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

Por favor, no el paquete diferente.

Answer 2

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

Mirando el rastro de la pila ApplicationFilterConfig.java:248 podría ser el culpable. O, glassfish está inicializando los filtros en el contexto incorrecto, para comparar, Tomcat inicializa los filtros durante BootStrap.

Answer 3

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

el escaneo de componentes de primavera funciona dos veces en archivos xml. genera beans dentro de SpringConfig.java cada tiempo de ejecución. luego se creó el administrador de caché duplicado.

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

Answer 4

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

El truco es recuperar la instancia de caché del bean, en ese caché obtener 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 elimina de la máquina virtual 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;
}

Answer 5

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

Answer 6

Lo resolví agregando follow to resources.groovy:

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

Answer 7

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

QUITAR en application.yml

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

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

Answer 8

Para 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, que ya contenía la biblioteca ehcache, y luego importé explícitamente net.sf.ehache libray.

Esto parecía funcionar bien cuando estaba corriendo como una aplicación independiente (una utilidad de línea de comandos, 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 corría en un contenedor Tomcat, me interesaría saber ...

Answer 9

Para la posteridad: una mejor manera es usar la propiedad "accept-existing" de EhCacheManagerFactoryBean .

Answer 10

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. allí está 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, como este:

 <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 recibo la misma excepción "Otro CacheManager sin nombre ya existe en la misma máquina virtual"

Answer 11

Su EhCacheManagerFactoryBean puede ser un singleton, pero está construyendo múltiples CacheManagers y tratando de darles el mismo nombre. Eso viola la semantics Ehcache 2.5.

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

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

Indique al frijol de fábrica que cree una instancia compartida de CacheManager en la JVM estableciendo la propiedad shared en verdadero.

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

Answer 12

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

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

Answer 13

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

Eso hizo el truco 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 sé las implicaciones de gran alcance de eso.

• http://forums.terracotta.org/forums/posts/list/6495.page
• norrisshelton.wordpress.com/2012/03/08/…

Answer 14

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