Un altro CacheManager senza nome esiste già nella stessa VM (ehCache 2.5)

Questo è quello che succede quando eseguo i miei test di 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 ] 

Qual è la ragione dietro l’eccezione. Potrebbe esserci più di 1 cacheManager in esecuzione contemporaneamente?

Ecco come ho configurato il cachManager usando Sping 3.1.1. Imposta esplicitamente l’ambito di cacheManager su “singleton”

   

Il file ehcache.xml è simile

  ....  

Finalmente la mia class

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

Sono sicuro che ho a che fare con un solo cacheManager nella mia base di codice. Qualcos’altro sta probabilmente eseguendo l’istanza n-esima.

EhCacheManagerFactoryBean potrebbe essere un singleton, ma sta creando più CacheManager e sta tentando di dare loro lo stesso nome. Ciò viola la semantica di Ehcache 2.5.

Le versioni di Ehcache precedenti alla versione 2.5 consentivano a qualsiasi numero di CacheManager con lo stesso nome (stessa risorsa di configurazione) di esistere in una JVM.

Ehcache 2.5 e versioni successive non consentono a più CacheManager con lo stesso nome di esistere nella stessa JVM. I costruttori di CacheManager () che creano CacheManager non Singleton possono violare questa regola

Comunica al bean factory di creare un’istanza condivisa di CacheManager nella JVM impostando la proprietà condivisa su true.

  

Ho avuto lo stesso problema con i miei test di integrazione usando JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). Il problema è stato risolto utilizzando la seguente configurazione di Hibernate:

  

invece di usare

  

Il tuo problema è l’ottimizzazione del caricamento del contesto costruita nel framework di test di Spring. Spring (per impostazione predefinita) non distrugge il contesto una volta terminata la class di test, nella speranza che un’altra class di test possa riutilizzarla (anziché crearla da zero).

È ansible sovrascrivere questo valore predefinito usando @DirtiesContext oppure, se si utilizza Maven, è ansible impostare surefire forkMode su “always” e creare una nuova VM per class di test.

Puoi anche provare a impostare il nome “xxx” sulla configurazione di ehcache.xml (sull’elemento ehcache).

Questo ha fatto il trucco per me, perché penso di avere un’altra configurazione cache in agguato in uno dei moduli della mia app.

La soluzione condivisa funziona anche, ma non conosco le implicazioni di vasta portata di ciò.

Dopo l’aggiornamento a Hibernate 5 ho dovuto usare:

  

invece di:

  

Per favore non il diverso pacchetto.

Per i posteri: un modo migliore è usare la proprietà “accept-existing” di EhCacheManagerFactoryBean .

se si esegue il test del proprio servizio aziendale, non della cache di secondo livello, è ansible rimuovere la configurazione di secondo livello nel file di configurazione di spring, il test verrà eseguito correttamente. c’è la mia configurazione di secondo livello:

        ${hibernate.dialect} false  false false    

se cambio la configurazione completa della configurazione di cache di secondo livello, la vera webapp viene usata in tempo di esecuzione, come questa:

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

poi ottengo la stessa eccezione “Un altro CacheManager senza nome esiste già nella stessa VM”

Nel mio caso, abbiamo un gestore cache personalizzato definito come bean. Anche un contesto applicativo personalizzato, quindi non usiamo il jner spring runner … quindi il @DirtiesContext non funziona.

Il trucco è recuperare l’istanza cache dal bean, su quella cache ottenere il cacheManager (l’istanza da EHCache). e su quel cache manager chiama il metodo removeCache.

Metti questo in un metodo annotato con @After e la tua cache viene rimossa dalla VM dopo ogni test. Come questo:

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

L’ho risolto aggiungendo seguendo a resources.groovy:

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

È successo a me quando si passa a Spring Boot 2.0.2 . Risolto facendo quanto segue:

RIMUOVERE in application.yml

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

RIMUOVERE in pom.xml

  net.sf.ehcache ehcache  

CONSERVARE solo in pom.xml

  org.hibernate hibernate-ehcache  

Per i futuri lettori, la causa di questo problema nel mio caso era che nel mio file pom.xml avevo importato la libreria hibernate-ehcache, che a me sconosciuta conteneva già la libreria ehcache, e quindi ho importato esplicitamente il file net.sf.ehache libray.

Questo sembrava funzionare bene quando ero in esecuzione come app standalone (un programma di utilità della riga di comando, ad esempio) ma causava l’errore nel post originale quando si eseguiva su un server tomcat.

Cambiando il mio file pom da:

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

A:

   org.hibernate hibernate-ehcache 5.0.2.Final   

Risolto il problema Se qualcuno ha qualche idea del perché il problema è apparso solo quando è stato eseguito in un contenitore di tomcat, sarei interessato a sapere …

In glassfish 3.0.1, ho rintracciato il problema di IniShiroFilter inizializzarlo due volte, cosa che accade quando vengono triggerste richieste simultanee subito dopo l’avvio del server. Di seguito è riportata una traccia stack da due thread diversi corrispondenti a due requisiti 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) 

Un altro 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) 

Guardando la traccia dello stack ApplicationFilterConfig.java:248 potrebbe essere il colpevole. Oppure, glassfish sta inizializzando i filtri nel contesto sbagliato, per il confronto, Tomcat inizializza i filtri durante BootStrap.

Nel mio caso Problem è component-scan e java config.

 root-context.xml  servlet-context.xml  

spring component-scan funziona due volte su file xml. genera bean all’interno di SpringConfig.java ogni volta. quindi è stato creato il gestore della cache duplicato.

così, l’ho cambiato come di seguito.

 root-context.xml    servlet-context.xml    

Questo errore si verifica anche con file di mapping errati. Il messaggio è orribile, non dice la causa.