이름이 지정되지 않은 다른 CacheManager가 동일한 VM에 이미 있습니다(ehCache 2.5).
이게 바로 내가 시험해봤을 때 일어나는 일이야
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 ]
예외의 배경은 무엇입니까?여러 cache Manager를 동시에 실행할 수 있습니까?
Sping 3.1.1을 사용하여 cachManager를 이렇게 설정했습니다.cacheManager의 범위를 명시적으로 "singleton"으로 설정합니다.
<ehcache:annotation-driven />
<bean
id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
scope="singleton"
/>
ehcache.xml은 다음과 같습니다.
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="false"
maxBytesLocalHeap="100M"
name="cacheManager"
>
....
</ehcache>
드디어 우리 반
@Component
public class BookingCache implements CacheWrapper<String, BookingUIBean> {
@Autowired
private CacheManager ehCacheManager;
....
}
코드 베이스에서 cacheManager를 취급하고 있는 것은 1개뿐입니다.다른 무언가가 n번째 인스턴스를 실행하고 있을 수 있습니다.
EhCacheManagerFactoryBean은 싱글톤일 수 있지만 여러 CacheManager를 구축하여 동일한 이름을 부여하려고 합니다.이는 Ehcache 2.5 의미론에 위배됩니다.
버전 2.5 이전 Ehcache에서는 동일한 이름(동일한 구성 리소스)을 가진 Cache Manager를 JVM에 얼마든지 배치할 수 있었습니다.
Ehcache 2.5 이상에서는 동일한 이름을 가진 여러 Cache Manager를 동일한 JVM에 배치할 수 없습니다.비싱글톤 CacheManager를 생성하는 CacheManager() 컨스트럭터는 이 규칙을 위반할 수 있습니다.
공유 속성을 true로 설정하여 JVM에 CacheManager의 공유 인스턴스를 생성하도록 팩토리 빈에 지시합니다.
<bean id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
p:shared="true"/>
JPA(2.0) + 휴지 상태(3.6.4) + 스프링(3.2.4)를 사용한 연동 테스트에서도 같은 문제가 발생했습니다.이 문제는, 다음의 휴지 상태 설정으로 해결.
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
사용하는 대신
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
문제는 스프링 테스트 프레임워크에 내장된 컨텍스트 로딩 최적화입니다.스프링(기본값 기준)은 테스트클래스가 완료되면 컨텍스트를 파기하지 않습니다.이는 (처음부터 작성하는 것이 아니라) 다른 테스트클래스가 재사용될 수 있기 때문입니다.
@DirtiesContext를 사용하여 이 기본값을 재정의하거나 maven을 사용하는 경우 surefire forkMode를 "항상"으로 설정하고 테스트 클래스별로 새 VM을 생성할 수 있습니다.
Hibernate 5로 업그레이드한 후 다음을 사용해야 했습니다.
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>
다음 대신:
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
패키지가 서로 다르기 때문에 주의해 주십시오.
또한 ehcache.xml 구성(ehcache 요소)에서 name"xxx"를 설정할 수도 있습니다.
내 앱 모듈 중 하나에 다른 캐시 구성이 숨어 있는 것 같아.
공유 솔루션도 작동하지만, 그 영향이 광범위할지는 모르겠습니다.
- http://forums.terracotta.org/forums/posts/list/6495.page
- https://norrisshelton.wordpress.com/2012/03/08/spring-3-1-caching-abstraction-with-ehcache/
후대: EhCacheManagerFactoryBean의 "accept-existing" 속성을 사용하는 것이 좋습니다.
의 설정EhCacheManagerFactoryBean#shared로로 합니다.true날 위해 일했어
의 설정EhCacheManagerFactoryBean#acceptExisting로로 합니다.true나한테는 안 통했어
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;
}
}
"XML을 사용하지 않는 Spring 4의 EhCache 사용"에서 설명한 바와 같이
second level cache가 아닌 비즈니스 서비스를 테스트하는 경우 spring config 파일에서 second level 구성을 삭제하면 테스트가 정상적으로 실행됩니다.두 번째 레벨 설정은 다음과 같습니다.
<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>
second level cache config 전체 구성으로 변경하면 실제 웹 앱은 다음과 같이 실행 시 사용됩니다.
<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>
동일한 예외 "이름 없는 다른 CacheManager가 같은 VM에 이미 존재합니다."
여기에서는 커스텀 캐시 매니저가 bean으로 정의되어 있습니다.또, 커스텀 애플리케이션 콘텍스트를 사용하고 있기 때문에, 스프링 Junit Runner를 사용하지 않습니다.따라서 @DirtiesContext가 작동하지 않습니다.
문제는 빈에서 캐시 인스턴스를 가져와 캐시에서 cacheManager(EHCache의 인스턴스)를 얻는 것입니다.캐시 매니저에서 removeCache 메서드를 호출합니다.
이것을 @After로 주석을 단 메서드에 넣으면 각 테스트 후 캐시가 VM에서 제거됩니다.다음과 같이 합니다.
@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;
}
resources.groovy에 다음 항목을 추가하여 해결했습니다.
콩 = {... aclCacheManager(EhCacheManagerFactoryBean) {shared = true}...}
Spring Boot 2.0.2로 전환했을 때 발생하였습니다.다음의 순서에 따라서 해결.
application.yml의 REMOVE
spring.jpa.properties.hibernate.cache.region.factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory
pom.xml에서 제거
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
</dependency>
pom.xml에만 KEEP
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
</dependency>
미래의 독자들에게 이 문제의 원인은 pom.xml 파일에서 hibernate-ehcache 라이브러리를 Import했기 때문입니다.이 라이브러리는 이미 ehcache 라이브러리를 포함하고 있으며 net.sf.ehache libray도 명시적으로 Import하고 있습니다.
스탠드아론 앱(커맨드라인 유틸리티 등)으로 실행할 때는 정상적으로 동작하는 것처럼 보였지만 Tomcat 서버에서 실행할 때는 원래 게시물에 오류가 발생하였습니다.
POM 파일 변경 위치:
<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>
수신인:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.0.2.Final</version>
</dependency>
<!-- ehcache dependency removed -->
문제를 해결했다.Tomcat 컨테이너에서 실행할 때만 문제가 발생한 이유를 알고 있는 사람이 있다면 알고 싶습니다.
glassfish 3.0.1에서는 IniShiroFilter가 2회 초기화되는 것을 추적했습니다.이것은 서버 기동 직후에 동시 요구가 발생했을 경우에 발생합니다.다음으로 2개의 HTTP requet에 대응하는2개의 다른 스레드로부터의 스택트레이스를 나타냅니다.
[#|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)
다른 스레드
[#|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)
스택 트레이스 ApplicationFilterConfig.java:248이 원인일 수 있습니다.또는 Glassfish가 잘못된 컨텍스트에서 필터를 초기화합니다. 비교를 위해 Tomcat은 BootStrap 중에 필터를 초기화합니다.
제 경우 문제는 component-scan과 java config입니다.
root-context.xml
<context:component-scan base-package="org.beansugar">
servlet-context.xml
<context:component-scan base-package="org.beansugar">
spring component-scan은 xml 파일에서 2회 동작합니다.실행 시마다 SpringConfig.java 내에 콩을 생성합니다.중복 캐시 매니저가 생성되었습니다.
그래서 이렇게 바꿨어요.
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>
이 오류는 잘못된 매핑 파일에서도 발생합니다.그 메시지는 끔찍해요, 원인은 말하지 마세요.
이 경우 설정은 다음과 같습니다.
<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>
EHCache 프로바이더 클래스를 변경한 것이 도움이 되었습니다.캐시 프로바이더 클래스를 사용하여org.hibernate.cache.EhCacheProvider대신 이것을 다음과 같이 변경했습니다.net.sf.ehcache.hibernate.SingletonEhCacheProvider
Spring Boot 2.1.2에서는 다음 구성으로 문제를 해결할 수 있었습니다.(이러한 것은 설정 전체의 일부입니다).
의존관계:
<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 설정:
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
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>
현재 작업 중인 응용 프로그램이 캐시가 작동하지 않으면 속도가 급격히 느려집니다.검증하기 위해 애플리케이션을 실행하고 읽기 집약적인 엔드포인트 중 하나를 검색하기만 하면 됩니다.
이 빈(eHCache 2.10)에 의해 Manager가 작성되었습니다.
<bean id="ehcache"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="shared" value="false"/>
</bean>
이 방법으로 수동으로 파괴하는 것이 유일한 해결책입니다.
@Inject
private EhCacheManagerFactoryBean ehCacheManagerFactoryBean;
그리고 나서.
ehCacheManagerFactoryBean.destroy();
언급URL : https://stackoverflow.com/questions/10013288/another-unnamed-cachemanager-already-exists-in-the-same-vm-ehcache-2-5
'programing' 카테고리의 다른 글
| 'toBeInTheDocument' 속성이 'Matchers' 유형에 없습니다. (0) | 2023.02.18 |
|---|---|
| Java에서 JSON을 XML로 변환 (0) | 2023.02.15 |
| FormControl은 무엇에 사용됩니까?왜 쓰이죠?사용방법 (0) | 2023.02.15 |
| 예외:'ngFor'는 알려진 네이티브 속성이 아니므로 바인딩할 수 없습니다. (0) | 2023.02.15 |
| 각도로 선택 초기화 중JS 및 ng-반복 (0) | 2023.02.15 |