티스토리 뷰
본 포스팅은 ClassLoader 및 Class 동적 반영에 대해 알아보도록 하겠습니다.
1. JEUS ROOT CLASSLOADER에 추가 되는 순서와 Library
• -Djeus.prepend.classpath (patch 적용시 사용하는 옵션 내용) & $JEUS_HOME/lib/jext/jext*.jar
(since JEUS6 fix7 이후버전에서 patch 적용 위치)
• lib/system/jext*.jar
• lib/system/jeus.jar
• lib/system/tools.jar
• lib/system/*.jar or *.zip except for jeus.jar, extension.jar, and bootstrap.jar
• lib/application/
• lib/thirdparty/*.jar or *.zip
• lib/application/*.jar or *.zip
• lib/datasource/*.jar or *.zip
• -Djeus.server.classpath (container의 경우는 user-class-path)
• -Djeus.server.dir
[내 용]
2. CLASSLOADING 방식의 이해
2-1. ISOLATED 방식 : 표준 방식
1) ISOLATED 방식으로 WEB에서 EJB 호출 시
(1) WEB Application에 EJB의 home, bean, object, stub,skeleton class를 Copy 한 후 참조 및 호출가능하다.
(2) Copy 위치 : $WEBHOME/WEB-INF/classes (class 파일로 존재) $WEBHOME/WEB-INF/lib (jar파일로 존재)
(3) stub, skeleton class는 JEUSMain.xml의 <class-ftp>true</class-ftp> 옵션을 true로 설정 시 copy 하지 않아도 사용할 수 있다. 위의 옵션을 넣더라도 EJB의 home, bean, object class는 copy를 해야 호출 가능하다.
2) WEB과 EJB가 서로 참조해야 하는 library 인 경우 JEUS root Class loader가 읽도록 하거나, EAR 모듈로 구성한다.
2-2. SHARED 방식
1) SHREAD방식으로 WEB에서 EJB 호출 시 (동일 Container만 가능)
(1) WEB Application에 EJB의 모든 class를 Copy 하지 않아도 참조 및 호출이 가능하다. (둘다 SHARED 된 경우)
(2) WEB과 EJB는 CLASS를 공유하고 있기 때문에 EJB나 WEB중 하나만 변경 되더라도 Application시 둘 다 redeploy 해야 한다.
# SHREAD의 의미
EJB의 SHARED는 자신의 class를 WEB에 노출. WEB의 SHARED 된 EJB Class를 참조 하겠다는 의미이다.
3 SHARED 방식 인 경우 사용되는 ClassLoader
1) Root ClassLoader : jeus.server.RootClassLoader
2) Servlet ClassLoader : jeus.servlet.loader.ContextLoader : WEB-INF/classes, WEB-INF/lib 라이브러리
3) EJB ClassLoader : jeus.ejb.util.EJBRootClassLoader : EJB 의 class
4) SHARED 옵션 ClassLoader : jeus.service.archive.ArchiveArrayClassLoader : 동일 container의 web application에서 EJB library 읽는 경우
<application><classloading>SHARED</classloading></application>
4. loading 된 class 들 확인 옵션
[설정 내용]
<engine-container>
<name>container1</name>
<command-option>-Xms256m -Xmx512m -verbose</command-option>
[로그 내용]
[Loaded jeus.util.oneport.OnePortIOFactory from file:/C:/TmaxSoft/JEUS6.0/lib/system/jeusutil.jar]
[Loaded jeus.util.oneport.JDK14OnePortIOFactory from
file:/C:/TmaxSoft/JEUS6.0/lib/system/jeusutil.jar]
[Loaded jeus.util.oneport.SocketChannelOnePortInputStream from
file:/C:/TmaxSoft/JEUS6.0/lib/system/jeusutil.jar]
[Loaded jeus.util.oneport.SocketOnePortInputStream from
file:/C:/TmaxSoft/JEUS6.0/lib/system/jeusutil.jar]
[Loaded jeus.util.oneport.JDK13OnePortSocket from
file:/C:/TmaxSoft/JEUS6.0/lib/system/jeusutil.jar]
[Loaded jeus.util.oneport.JDK14OnePortSocket from
file:/C:/TmaxSoft/JEUS6.0/lib/system/jeusutil.jar]
위와 같이 Webapplication / EJB를 혼용하여 사용하는 Enterprise Archive의 경우 각각의 Class를 로딩하여 사용하기 위해 Shared라는 옵션을 사용합니다.
다음으로 Class 동적반영입니다.
directory 모드의 Application 에 대해 class 변경이 빈번하여, 동적 reload 가 필요한 경우, 이를 적용하는 2가지 방법에 대해서 기술 합니다. 운영 시에는 class 동적 반영을 하지 않는 것을 권고 합니다.
1. 반영 방법
a. jeus-web-dd.xml 설정 변경
<check-on-demand>true</check-on-demand>
- 해당하는 클래스의 요청이 있는 경우마다 class의 변경 유무를 확인하여 reloading하는 방식으로 운영이 아닌 개발용도로 사용하는 옵션이다.
[설정 방법]
$APPLICATION_HOME/WEB-INF/jeus-web-dd.xml 설정
<check-on-demand>true</check-on-demand>
<enable-reload>true</enable-reload>
<enable-reload>true</enable-reload>
위 check-on-demand 옵션을 사용하지 않고 엔진 내부적으로 주기적인 간격(디폴트 : 5분)에 의해 변경된 클래스 체크 및 loading을 하는 옵션.
해당 옵션은 주기적으로 클래스의 변경 여부를 체크하기 때문에 수행 시점에 CPU 사용률이 상대적으로 약간 높아질 수가 있으며, 이는 배포된 클래스의 수 및 시스템의 사양에 따라 각기 다르기 때문에 정확한 CPU 사용량은 실제 운영 장비에서 모니터링을 하면 확인이 가능.
[설정 방법]
$APPLICATION_HOME/WEB-INF/jeus-web-dd.xml 설정
<check-on-demand>false</check-on-demand>
<enable-reload>true</enable-reload>
$JEUS_HOME/config/[node명]/[node명]_servlet_엔진명/WEBMain.xml 설정
<monitoring>
<check-thread-pool>60000</check-thread-pool>
<check-class-reload>60000</check-class-reload>
</monitoring>
2. jeusadmin의 webreload 기능 사용
reload 관련한 두 옵션이 모두 'false'로 지정하여 엔진 내부에서 reload 기능을 사용하지 않는 경우 JEUS에서 제공하는 command를 이용하여 필요 시점에 관리자가 직접 해당 ContextGroup을 대상으로 reload 하는 옵션입니다.
[내 용]
$APPLICATION_HOME/WEB-INF/jeus-web-dd.xml 설정
<check-on-demand>false</check-on-demand>
<enable-reload>false</enable-reload>
JEUS ADMIN Command 실행 내용
[ibmtest:/user/mkko]$ ja
JEUS 6.0 (Fix#6) JEUS administration tool
ibmtest>webreload -con ibmtest_container1 MyGroup
< ContainerName : ibmtest_container1 >
reload sucessful
[실행 내용]
[2013.01.11 10:56:38][2][b216] [container1-4] [WEB-3480] context (test) is started successfully
[2013.01.11 10:56:38][2][b216] [container1-4] [WEB-3482] reloading a context(test) is completed successfully
3. 클래스 재 로딩 시 고려할 사항
30초 이상 수행되는 요청이 있는 경우 해당 처리가 끝날 때 까지(30초) 대기하게 되며 대기시간이 이를 초과하는 경우에는 아래와 같은 에러와 함께 Reloading 하지 않고 다음 reloading 주기 및 시점에 다시 reloading 처리를 하는 방식으로 동작합니다.
jeus.servlet.deployment.StartingException: failed to doReload() because of timeout
at jeus.servlet.engine.Context.doReload(Context.java:1299)
at jeus.servlet.engine.Context.execReload(Context.java:893)
at jeus.servlet.engine.RequestProcessor.doWorkRelatedReload(RequestProcessor.java:39
at jeus.servlet.engine.WebtobRequestProcessor.run(WebtobRequestProcessor.java:168)
이번 시간에는 JEUS ClassLoader와 동적 반영 방법에 대해 알아보았습니다.
다음시간에 뵙겠습니다.
고맙습니다.
'④ 미들웨어 > ⓙ JEUS' 카테고리의 다른 글
[JEUS] JSP Compile 시 code too large 에러 발생하는 경우 (0) | 2018.07.17 |
---|---|
[Web Application Server] JEUS7 중복로그인 방지기능 (2) | 2018.07.10 |
[JEUS] Oracle/Tibero 접속세션 구분 방법 (0) | 2018.07.04 |
[JEUS] Encoding 설정에 따른 출력 Test (2) | 2018.07.03 |
[Web Application Server] JEUS7 Password 변경 가이드 (0) | 2018.07.03 |
- Total
- Today
- Yesterday
- OpenStack
- git
- webtob
- k8s
- TA
- Da
- 오픈스택
- 마이크로서비스 아키텍처
- JBoss
- JEUS7
- wildfly
- kubernetes
- node.js
- openstack token issue
- SA
- JEUS6
- jeus
- Architecture
- 쿠버네티스
- apache
- nodejs
- MSA
- openstack tenant
- aa
- 마이크로서비스
- API Gateway
- SWA
- 아키텍처
- Docker
- aws
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |