Một CacheManager không tên khác đã tồn tại trong cùng một máy ảo (ehCache 2.5)


76

Đây là những gì xảy ra khi tôi chạy các bài kiểm tra tháng sáu của mình ...

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 ]

Lý do đằng sau ngoại lệ là gì. Có thể có nhiều hơn 1 cacheManager chạy đồng thời không?

Đây là cách tôi định cấu hình cachManager bằng Sping 3.1.1. Nó đặt rõ ràng phạm vi của cacheManager thành "singleton"

<ehcache:annotation-driven />

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

Ehcache.xml trông giống như

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

Cuối cùng là lớp của tôi

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

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

Tôi rất chắc chắn rằng tôi đang xử lý duy nhất một cacheManager trong cơ sở mã của mình. Một cái gì đó khác có thể đang chạy phiên bản thứ n.


4
Tôi đã gặp vấn đề tương tự với ehCache 2.5 hoặc cao hơn. Sử dụng 2.4.7 không gây ra vấn đề này, nhưng sẽ rất tốt nếu bạn biết cách làm cho 2.5 trở nên thân thiện với junit.
aweigold

1
Cảm ơn. Tôi đã chuyển trở lại 2.4.7, hiện vẫn ổn. Ngoài ra còn có một mục blog thảo luận về các cách giải quyết có thể xảy ra (mặc dù cả hai đều không có vẻ hấp dẫn lắm) norrisshelton.wordpress.com/2012/03/08/…
simou

Giải pháp của Norris Shelton phù hợp với tôi ( norrisshelton.wordpress.com/2012/03/08/… )
jbbarquero

Giải pháp này dường như không hiệu quả với tôi, tôi đang sử dụng testNG. Tôi vẫn nhận được "Một CacheManager khác có cùng tên 'myCacheManager' đã tồn tại trong cùng một máy ảo" :(
nodje

Tôi tin rằng [ở đây] [1] cũng giải quyết được vấn đề. [1]: stackoverflow.com/questions/11139653/…
Lekkie

Câu trả lời:


46

EhCacheManagerFactoryBean của bạn có thể là một singleton, nhưng nó đang xây dựng nhiều CacheManagers và cố gắng đặt chúng cùng một tên. Điều đó vi phạm ngữ nghĩa của Ehcache 2.5 .

Các phiên bản của Ehcache trước phiên bản 2.5 cho phép bất kỳ số lượng CacheManagers nào có cùng tên (tài nguyên cấu hình giống nhau) tồn tại trong JVM.

Ehcache 2.5 trở lên không cho phép nhiều CacheManagers có cùng tên tồn tại trong cùng một JVM. Các hàm tạo CacheManager () tạo không phải Singleton CacheManagers có thể vi phạm quy tắc này

Yêu cầu factory bean tạo một phiên bản dùng chung của CacheManager trong JVM bằng cách đặt thuộc tính chia sẻ thành true.

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

5
Một điều cần lưu ý, nếu Spring đang tự động in EhCacheManagerFatoryBean, bạn vẫn có thể gặp lỗi ngay cả khi bạn đặt p: shared thành true. Cách khắc phục điều này là không sử dụng tên mặc định cho tệp của bạn, thay vì sử dụng ehcache.xml, đổi tên tệp và thêm p: config-location vào khai báo EhCacheManagerFactoryBean của bạn với tên tệp mới.
TechTrip

1
@TechTrip: Tôi đã làm chính xác điều đó: Tôi đã sử dụng p:config-location="classpath:ehcache-foo.xml" p:shared="true"EhCacheManagerFactoryBean của mình, nhưng tôi gặp xung đột vì hai WAR trên JVM của tôi sử dụng cùng một mô-đun này.
mcv

3
Hãy sửa cho tôi nếu tôi sai, nhưng điều này không có nghĩa là thử nghiệm thứ hai sẽ sử dụng lại bộ nhớ cache từ thử nghiệm đầu tiên với bất kỳ dữ liệu đã lưu trong bộ nhớ cache nào vẫn còn trong đó? Điều này có thể dẫn đến hành vi khó gỡ lỗi vì thử nghiệm thứ hai không bắt đầu ở trạng thái đã biết. Kết quả thử nghiệm sau đó có thể phụ thuộc vào thứ tự thử nghiệm. (Tất nhiên các bài kiểm tra hộp đen không nên phụ thuộc vào việc bộ nhớ đệm có được sử dụng hay không, nhưng việc kiểm tra hiệu suất phụ thuộc vào trạng thái bộ đệm là hoàn toàn hợp lệ hoặc có lẽ bạn đang kiểm tra bộ nhớ đệm sử dụng ehcache bên dưới.)
Henno Vermeulen

42

Tôi đã gặp vấn đề tương tự với các bài kiểm tra tích hợp của mình bằng JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). Sự cố đã được giải quyết bằng cách sử dụng cấu hình Hibernate sau:

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

thay vì sử dụng

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

3
Tôi đã điều chỉnh giải pháp này để khắc phục sự cố thử nghiệm Spring Boot của mình: Tôi đã sử dụng org.hibernate.cache.ehcache.EhCacheRegionFactory thay vì net.sf.ehcache.hibernate.EhCacheRegionFactory cho Hibernate 4 . Với Spring Boot, bạn có thể đặt điều này trong application.properties: spring.jpa.properties.hibernate.cache.region.factory_class = org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory hoặc với @TestPropertySource nếu bạn muốn giới hạn cấu hình kiểm tra.
Michael Koch

1
Chà, đã lưu một ngày của tôi sau khi nâng cấp từ chế độ ngủ đông 4.3.x lên 5.2.
smallufo 14/09/16

22

Vấn đề của bạn là tối ưu hóa tải ngữ cảnh được xây dựng trong khuôn khổ thử nghiệm Spring. Spring (theo mặc định) không phá hủy ngữ cảnh sau khi lớp thử nghiệm được thực hiện, với hy vọng rằng một lớp thử nghiệm khác có thể sử dụng lại nó (thay vì tạo nó từ đầu).

Bạn có thể ghi đè mặc định này bằng @DirtiesContext hoặc nếu bạn sử dụng maven, bạn có thể đặt surefire forkMode thành "luôn luôn" và tạo một máy ảo mới cho mỗi lớp thử nghiệm.


3
Điều này giải quyết vấn đề một cách rõ ràng cho các môi trường thử nghiệm mà không thay đổi cấu hình thời gian chạy thực tế của bạn. Đẹp!
mất

2
forkmode = luôn luôn là một lời kêu gọi tốt nhưng không được chấp nhận. xem: maven.apache.org/surefire/maven-surefire-plugin/examples/... TRY forkCount = 1 (mặc định), reuseForks = false
theINtoy

12

Bạn cũng có thể thử đặt tên "xxx" trên cấu hình ehcache.xml của mình (trên phần tử ehcache).

Đó là một mẹo nhỏ đối với tôi, vì tôi nghĩ rằng tôi có một cấu hình bộ nhớ cache khác ẩn trong một trong các mô-đun của ứng dụng của tôi.

Giải pháp được chia sẻ cũng hoạt động, nhưng tôi không biết ý nghĩa sâu xa của điều đó.


Đúng! Đó hóa ra là giải pháp duy nhất cho tôi. Thêm thuộc tính name vào phần tử echache trên cùng. Đó dường như không được ghi lại trong file ví dụ ehcache.xml ..
Nicolas Mommaerts

quá buồn mà tôi chỉ đọc câu trả lời đầu tiên ở đây, sau đó tôi quay trở lại trong nhật thực đọc tất cả các mùa xuân & ehcache init nguồn để tìm ra rằng thuộc tính tên là cần thiết nếu không thì tập tin cấu hình được bỏ qua ...
jpprade

giải pháp tốt, tôi đã cùng một ngoại lệ với hai bài kiểm tra đơn vị trong hai mô-đun khác nhau mà cả hai đã xảy ra để sử dụng ehcache, mỗi tập tin riêng của họ và giải quyết này vấn đề này
Henno Vermeulen

Thông minh. Nhưng tôi vẫn không thể hiểu làm thế nào nó có thể giải quyết vấn đề bằng cách đặt tên thành ehcache.xml? Tôi đang sử dụng bộ đệm mùa xuân + bộ đệm ẩn cấp 2 ngủ đông. Cả hai đều đang sử dụng cùng một ehcache.xml.
santu

1
Giải pháp này chỉ hoạt động với các cấu hình xung đột (một số tệp ehcache.xml), nếu bạn chỉ sử dụng một cấu hình thì đó có thể là một vấn đề khác.
Michael Holst

12

Sau khi nâng cấp lên Hibernate 5, tôi phải sử dụng:

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

thay vì:

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

Xin lưu ý rằng các gói khác nhau.



2

Nếu bạn chỉ kiểm tra dịch vụ doanh nghiệp của mình, không phải bộ nhớ cache cấp hai, bạn có thể xóa cấu hình cấp hai trong tệp cấu hình mùa xuân của mình, thử nghiệm của bạn sẽ chạy thành công. có cấu hình cấp hai của tôi:

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

nếu tôi thay đổi thành cấu hình đầy đủ của cấu hình bộ đệm cấp hai, ứng dụng web thực sự sẽ sử dụng trong thời gian chạy, như thế này:

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

thì tôi nhận được cùng một Ngoại lệ "Một CacheManager không tên khác đã tồn tại trong cùng một máy ảo"


2

Trong trường hợp của tôi, chúng tôi có một trình quản lý bộ nhớ cache tùy chỉnh được định nghĩa là bean. Cũng là một ngữ cảnh ứng dụng tùy chỉnh nên chúng tôi không sử dụng Spring junit runner ... do đó @DirtiesContext không hoạt động.

Bí quyết là lấy thể hiện bộ nhớ cache từ bean, trên bộ đệm đó lấy cacheManager (thể hiện từ EHCache). và trên trình quản lý bộ nhớ cache đó gọi phương thức removeCache.

Đặt điều này trong một phương thức được chú thích bằng @After và bộ nhớ cache của bạn sẽ bị xóa khỏi VM sau mỗi lần kiểm tra. Như thế này:

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

2

Tôi đã giải quyết nó bằng cách thêm phần sau vào resources.groovy:

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


2

Điều đó đã xảy ra với tôi khi chuyển sang Spring Boot 2.0.2 . Giải quyết nó bằng cách làm như sau:

LOẠI BỎ trong application.yml

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

LOẠI BỎ trong pom.xml

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

CHỈ GIỮ trong pom.xml

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

2

Đặt EhCacheManagerFactoryBean#sharedthànhtrue làm việc cho tôi.

Đặt EhCacheManagerFactoryBean#acceptExistingthành trueDIDN'T đối với tôi.

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

Như đã giải thích trong Sử dụng EhCache trong Spring 4 mà không cần XML


1

Đối với những người đọc trong tương lai, nguyên nhân của sự cố này trong trường hợp của tôi là trong tệp pom.xml của tôi, tôi đã nhập thư viện hibernate-ehcache, thư viện mà tôi không biết cũng đã chứa thư viện ehcache và sau đó nhập net.sf.ehache một cách rõ ràng. libray.

Điều này dường như hoạt động tốt khi tôi đang chạy như một ứng dụng độc lập (một tiện ích dòng lệnh chẳng hạn) nhưng nó gây ra lỗi trong bài đăng gốc khi chạy trên máy chủ tomcat.

Thay đổi tệp pom của tôi từ:

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

Đến:

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

Đã khắc phục sự cố. Nếu ai đó có bất kỳ ý tưởng nào tại sao sự cố chỉ xuất hiện khi chạy trong thùng chứa tomcat, tôi muốn biết ..


0

Trong glassfish 3.0.1, tôi đã tìm ra vấn đề khiến IniShiroFilter khởi chạy hai lần, điều này xảy ra khi các yêu cầu đồng thời được kích hoạt ngay sau khi máy chủ khởi động. Sau đây là một dấu vết ngăn xếp từ hai luồng khác nhau tương ứng với hai yêu cầu 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)

Một chủ đề khác

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

Nhìn vào dấu vết ngăn xếp ApplicationFilterConfig.java:248 có thể là thủ phạm. Hoặc, glassfish đang khởi tạo bộ lọc trong ngữ cảnh sai, để so sánh, Tomcat khởi tạo bộ lọc trong BootStrap.


0

Trong trường hợp của tôi Vấn đề là quét thành phần và cấu hình java.

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

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

Spring component-scan hoạt động hai lần trên các tệp xml. nó tạo ra các bean bên trong SpringConfig.java mỗi lần chạy. thì trình quản lý bộ nhớ cache trùng lặp đã được tạo.

vì vậy, tôi đã thay đổi điều đó như bên dưới.

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>

0

Lỗi này cũng xảy ra với các tệp ánh xạ sai. Tin nhắn kinh khủng, không nói nguyên nhân.


0

Trong trường hợp của tôi, cấu hình như sau:

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

Thay đổi lớp nhà cung cấp EHCache đã thực hiện công việc cho tôi. Tôi đã sử dụng lớp nhà cung cấp bộ nhớ cache org.hibernate.cache.EhCacheProvidervì thay vào đó, tôi đã thay đổi lớp này thành: net.sf.ehcache.hibernate.SingletonEhCacheProvider


0

Kể từ Spring Boot 2.1.2 , cấu hình sau đã hoạt động để giải quyết vấn đề. (Lưu ý, đây là các đoạn mã của cấu hình tổng thể.)

Sự phụ thuộc:

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

Cấu hình application.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

Cấu hình 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>

Ứng dụng tôi đang làm việc chạy chậm lại đáng kể mà không có bộ nhớ cache hoạt động. Vì vậy, để xác thực, tôi chỉ cần chạy ứng dụng và nhấn một trong các điểm cuối cường độ cao đã đọc.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.