Ein anderer unbenannter CacheManager ist bereits in derselben VM vorhanden (ehCache 2.5)

76

Das passiert, wenn ich meine Junit-Tests durchführe ...

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 ]

Was ist der Grund für die Ausnahme? Könnte mehr als 1 cacheManager gleichzeitig ausgeführt werden?

So habe ich den cachManager mit Sping 3.1.1 konfiguriert. Der Bereich des cacheManager wird explizit auf "singleton" gesetzt.

<ehcache:annotation-driven />

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

Die ehcache.xml sieht aus wie

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

Endlich meine Klasse 

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

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

Ich bin mir sehr sicher, dass es sich nur um einen cacheManager in meiner Codebasis handelt. Etwas anderes führt wahrscheinlich die n-te Instanz aus.

spring junit ehcache simou
quelle
4
Ich habe das gleiche Problem mit ehCache 2.5 oder höher gesehen. Die Verwendung von 2.4.7 verursacht dieses Problem nicht, aber es wäre gut zu wissen, wie man 2.5 mit junit freundlich macht.
Ehrfurcht
1
Vielen Dank. Ich bin zurück zu 2.4.7 gewechselt, was vorerst in Ordnung ist. Es gibt auch einen Blogeintrag, in dem mögliche Problemumgehungen
simou
Die Lösung von Norris Shelton funktioniert für mich ( norrisshelton.wordpress.com/2012/03/08/… )
jbbarquero
Diese Lösung scheint bei mir nicht zu funktionieren, ich verwende jedoch testNG. Ich erhalte immer noch "Ein weiterer CacheManager mit demselben Namen 'myCacheManager' ist bereits in derselben VM vorhanden" :(
nodje
Ich glaube, [hier] [1] löst auch das Problem. [1]: stackoverflow.com/questions/11139653/…
Lekkie

Antworten:

46

Ihre EhCacheManagerFactoryBean ist zwar ein Singleton, erstellt jedoch mehrere CacheManager und versucht, ihnen denselben Namen zu geben. Dies verstößt gegen die Semantik von Ehcache 2.5 .

In Versionen von Ehcache vor Version 2.5 konnten in einer JVM beliebig viele CacheManager mit demselben Namen (derselben Konfigurationsressource) vorhanden sein.

Mit Ehcache 2.5 und höher können nicht mehrere CacheManager mit demselben Namen in derselben JVM vorhanden sein. CacheManager () -Konstruktoren, die Nicht-Singleton-CacheManager erstellen, können gegen diese Regel verstoßen

Weisen Sie die Factory-Bean an, eine gemeinsam genutzte Instanz des CacheManager in der JVM zu erstellen, indem Sie die gemeinsam genutzte Eigenschaft auf true setzen.

<bean id="cacheManager"
      class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
      p:shared="true"/>
Emerson Farrugia
quelle
5
Wenn Spring die EhCacheManagerFatoryBean automatisch kopiert, wird der Fehler möglicherweise trotzdem angezeigt, selbst wenn Sie p: shared auf true setzen. Um dies zu umgehen, verwenden Sie nicht den Standardnamen für Ihre Datei, sondern verwenden Sie ehcache.xml, um die Datei umzubenennen und Ihrer EhCacheManagerFactoryBean-Deklaration p: config-location mit dem neuen Dateinamen hinzuzufügen.
TechTrip
1
@TechTrip: Ich habe genau das getan: Ich habe p:config-location="classpath:ehcache-foo.xml" p:shared="true"auf meiner EhCacheManagerFactoryBean, und dennoch bekomme ich einen Konflikt, weil zwei WARs auf meiner JVM dasselbe Modul verwenden.
mcv
3
Korrigieren Sie mich, wenn ich falsch liege. Bedeutet dies nicht, dass ein zweiter Test den Cache des ersten Tests mit noch zwischengespeicherten Daten wiederverwendet? Dies kann zu einem schwer zu debuggenden Verhalten führen, da der zweite Test nicht in einem bekannten Zustand startet. Das Testergebnis kann dann von der Testreihenfolge abhängen. (Natürlich sollten Black-Box-Tests nicht davon abhängen, ob ein Cache verwendet wird oder nicht, aber es ist durchaus gültig, Leistungstests durchzuführen, die vom Cache-Status abhängen, oder Sie testen möglicherweise Ihr eigenes Caching-Dienstprogramm, das ehcache unter der Decke verwendet.)
Henno Vermeulen
41

Ich hatte das gleiche Problem mit meinen Integrationstests mit JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). Das Problem wurde mithilfe der folgenden Konfiguration im Ruhezustand behoben:

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

anstatt zu verwenden 

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
Felix Reckers
quelle
3
Ich habe diese Lösung angepasst, um meine Spring Boot- Testprobleme zu beheben: Ich habe org.hibernate.cache.ehcache.EhCacheRegionFactory anstelle von net.sf.ehcache.hibernate.EhCacheRegionFactory für Hibernate 4 verwendet . Mit Spring Boot können Sie dies in den application.properties festlegen: spring.jpa.properties.hibernate.cache.region.factory_class = org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory oder mit einer @ TestPropertySource, wenn Sie die Konfiguration auf die beschränken möchten Prüfung.
Michael Koch
1
Wow, ich habe meinen Tag nach dem Upgrade von Hibernate 4.3.x auf 5.2 gerettet.
Smallufo
22

Ihr Problem ist die im Spring-Test-Framework integrierte Optimierung zum Laden von Kontexten. Spring (standardmäßig) zerstört den Kontext nicht, sobald die Testklasse fertig ist, in der Hoffnung, dass eine andere Testklasse sie wiederverwendet (anstatt sie von Grund auf neu zu erstellen).

Sie können diese Standardeinstellung mit @DirtiesContext überschreiben. Wenn Sie maven verwenden, können Sie den todsicheren forkMode auf "immer" setzen und eine neue VM pro Testklasse erstellen.

Dejan P.
quelle
3
Dies löst das Problem sauber für Testumgebungen, ohne Ihre tatsächliche Laufzeitkonfiguration zu ändern. Nett!
verlor am
2
forkmode = ist immer ein guter Schrei, aber veraltet. Siehe: maven.apache.org/surefire/maven-surefire-plugin/examples/… TRY forkCount = 1 (Standard), reuseForks = false
theINtoy
12

Sie können auch versuchen, den Namen "xxx" in Ihrer ehcache.xml-Konfiguration (im ehcache-Element) festzulegen.

Das war der Trick für mich, da ich glaube, dass in einem der Module meiner App eine andere Cache-Konfiguration lauerte.

Die gemeinsame Lösung funktioniert auch, aber ich kenne die weitreichenden Auswirkungen davon nicht.

Michael Holst
quelle
Ja! Das stellte sich als die einzige Lösung für mich heraus. Hinzufügen des Namensattributs zum obersten Echache-Element. Das scheint nicht in der Beispieldatei ehcache.xml dokumentiert zu sein.
Nicolas Mommaerts
zu traurig, dass ich hier nur die erste Antwort gelesen habe, danach gehe ich zurück in Eclipse und lese die gesamte Quellquelle von spring & ehcache, um herauszufinden, dass das Namensattribut benötigt wird, andernfalls wird die Konfigurationsdatei ignoriert ...
jpprade
Gute Lösung, ich habe die gleiche Ausnahme mit zwei Unit-Tests in zwei verschiedenen Modulen bekommen, die beide zufällig ehcache verwendeten, jedes mit seiner eigenen Datei, und dies löst das Problem
Henno Vermeulen
Ausgezeichnet. Aber ich konnte immer noch nicht verstehen, wie das Problem behoben werden kann, indem der Name auf ehcache.xml gesetzt wird. Ich verwende den Spring Caching + Hibernate 2nd Level Cache. Beide verwenden dieselbe ehcache.xml.
Santu
1
Diese Lösung funktioniert nur mit widersprüchlichen Konfigurationen (mehrere ehcache.xml-Dateien). Wenn Sie nur eine verwenden, liegt möglicherweise ein anderes Problem vor.
Michael Holst
12

Nach dem Upgrade auf Hibernate 5 musste ich Folgendes verwenden:

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

Anstatt von:

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

Bitte beachten Sie, dass sich die Pakete voneinander unterscheiden.

Augen
quelle
6

Für die Nachwelt: Ein besserer Weg ist die Verwendung der Eigenschaft "Akzeptieren vorhanden" der EhCacheManagerFactoryBean .

Nishith
quelle
2

Wenn Sie nur Ihren Geschäftsdienst und nicht den Cache der zweiten Ebene testen, können Sie die Konfiguration der zweiten Ebene in Ihrer Spring-Konfigurationsdatei entfernen. Der Test wird erfolgreich ausgeführt. Es gibt meine Konfiguration der zweiten Ebene:

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

Wenn ich zur vollständigen Konfiguration der Cache-Konfiguration der zweiten Ebene wechsle, wird die reale Webanwendung zur Laufzeit wie folgt verwendet:

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

dann bekomme ich die gleiche Ausnahme "Ein anderer unbenannter CacheManager existiert bereits in derselben VM"

roger.li
quelle
2

In meinem Fall haben wir einen benutzerdefinierten Cache-Manager, der als Bean definiert ist. Auch ein benutzerdefinierter Anwendungskontext, sodass wir den Spring Junit Runner nicht verwenden ... daher funktioniert der @DirtiesContext nicht.

Der Trick besteht darin, die Cache-Instanz aus der Bean abzurufen und in diesem Cache den cacheManager (die Instanz aus EHCache) abzurufen. Rufen Sie auf diesem Cachemanager die Methode removeCache auf.

Fügen Sie dies in eine mit @After kommentierte Methode ein, und Ihr Cache wird nach jedem Test von der VM entfernt. So was:

@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
quelle
2

Ich habe es gelöst, indem ich folgende Ressourcen zu resources.groovy hinzugefügt habe:

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

Dasma
quelle
2

Es ist mir passiert, als ich zu Spring Boot 2.0.2 gewechselt bin . Es wurde wie folgt behoben:

ENTFERNEN in application.yml

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

ENTFERNEN in pom.xml

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

HALTEN Sie nur in pom.xml

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

Einstellen der EhCacheManagerFactoryBean#sharedzu truefür mich gearbeitet.

Einstellen der EhCacheManagerFactoryBean#acceptExistingauf truenicht für mich arbeiten.

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

Wie unter Verwenden von EhCache in Spring 4 ohne XML erläutert

Kumpel Šimović
quelle
1

Für zukünftige Leser war die Ursache für dieses Problem in meinem Fall, dass ich in meiner pom.xml-Datei die mir unbekannte Hibernate-Ehcache-Bibliothek importiert hatte, die auch bereits die EHCache-Bibliothek enthielt, und dann explizit die net.sf.ehache importierte libray.

Dies schien gut zu funktionieren, als ich als eigenständige App ausgeführt wurde (z. B. als Befehlszeilenprogramm), verursachte jedoch den Fehler im ursprünglichen Beitrag, wenn ich auf einem Tomcat-Server ausgeführt wurde.

Ändern meiner POM-Datei von:

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

Zu:

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

Das Problem wurde behoben. Wenn jemand eine Idee hat, warum das Problem nur beim Ausführen in einem Tomcat-Container auftrat, würde mich das interessieren.

Matt Watson
quelle
0

In glassfish 3.0.1 habe ich das Problem darauf zurückgeführt, dass IniShiroFilter zweimal initialisiert wurde. Dies geschieht, wenn gleichzeitige Anforderungen unmittelbar nach dem Start des Servers ausgelöst werden. Es folgt eine Stapelverfolgung von zwei verschiedenen Threads, die zwei HTTP-Anforderungen entsprechen:

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

Ein weiterer 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.<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)

Ein Blick auf den Stack-Trace ApplicationFilterConfig.java:248 könnte der Schuldige sein. Oder Glassfish initialisiert Filter im falschen Kontext. Zum Vergleich: Tomcat initialisiert Filter während BootStrap.

jsh
quelle
0

In meinem Fall ist das Problem der Komponentenscan und die Java-Konfiguration.

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

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

Spring Component-Scan funktioniert zweimal mit XML-Dateien. Es generiert zu jeder Laufzeit Beans in SpringConfig.java. Dann wurde ein doppelter Cache-Manager erstellt.

Also habe ich das wie unten geändert.

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>
Erzmagier
quelle
0

Dieser Fehler tritt auch bei falschen Zuordnungsdateien auf. Die Nachricht ist schrecklich, sagt nicht die Ursache.

ejaenv
quelle
0

In meinem Fall war die Konfiguration wie folgt:

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

Das Ändern der EHCache-Anbieterklasse hat den Job für mich erledigt. Ich habe die Cache-Provider-Klasse verwendet, da org.hibernate.cache.EhCacheProviderich diese stattdessen geändert habe in: net.sf.ehcache.hibernate.SingletonEhCacheProvider

Ritesh
quelle
0

Ab Spring Boot 2.1.2 hat die folgende Konfiguration das Problem behoben . (Beachten Sie, dass dies Ausschnitte aus der Gesamtkonfiguration sind.)

Abhängigkeiten:

<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

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

Die Anwendung, an der ich arbeite, wird ohne funktionierenden Cache drastisch verlangsamt. Zur Validierung habe ich einfach die Anwendung ausgeführt und einen der leseintensiven Endpunkte erreicht.

Kroolk
quelle