본 장에서는 JEUS 서버를 제어하고 모니터링하는 방법을 설명한다. 여기에서 설명하는 서버는 MS에 한정되며, 관리를 담당하는 DAS가 정상 동작 중이라고 가정한다. 설명한 내용은 WebAdmin을 통해서도 가능하므로 COMMAND Line에 익숙하지 않다면 WebAdmin을 사용할 것을 권장한다.
참고
서버 실행 스크립트와 콘솔 툴에 관한 자세한 사항은 “JEUS Reference Book”의 “제3장 JEUS 서버 실행”과 “JEUS Reference Book”의 “4.2.2. Local 명령어”를 참고한다.
본 절에서는 서버 제어 및 모니터링에 대해서 설명한다.
MS는 다음과 같은 동작 상태를 갖는다. MS의 상태는 DAS 또는 사용자에 의해 변경될 수 있다.
| 구분 | 설명 |
|---|---|
| SHTUDOWN | 서버가 아직 부팅되지 않았거나 정상적으로 종료된 상태이다. |
| STARTING | 서버가 시작 명령을 받고 부팅 중인 상태이다. 서버는 실행 스크립트 또는 노드 매니저에 의해서 시작될 수 있다. 이 단계에서 서버는 엔진(WEB, EJB, JMS) 생성, JEUS 서비스(보안, GMS 등) 실행, 그리고 등록된 애플리케이션 deploy 등의 작업을 수행한다. |
| STADNBY | 서버에서 실행되어야 하는 JEUS 서비스가 시작된 상태이다. 만약 서버가 이 상태로 부팅을 완료했다면 서버에 등록된 애플리케이션이 deploy를 실패한 것이다. 서버에 등록된 애플리케이션 distribute가 실패한 경우에도 서버는 STANDBY 상태에 머무르게 된다. |
| RUNNING | 서버가 부팅이 완료되고 등록된 애플리케이션들도 정상적으로 서비스되는 상태이다. 만약 STANDBY 상태의 서버를 -force 옵션을 통해 시작시킨 상황이라면 서버에 등록된 모든 애플리케이션이 서비스되지 못하는 상태일 수도 있다. |
| SUSPENDING | RUNNING 상태인 서버가 suspend 명령을 수행 중인 상태이다. 이 단계에서는 서버에서 서비스되고 있는 모든 애플리케이션의 서비스를 중단된다. 단, 애플리케이션 서비스를 위한 Listener는 내리지 않는다. |
| SUSPENDED | 서버에 deploy된 애플리케이션을 모두 중지시켜 서비스가 되지 않도록 멈춘 상태이다. 단, 애플리케이션 서비스를 위한 Listener는 내리지 않고 그대로 있다. |
| RESUMING | SUSPENDED 상태의 서버가 resume 명령을 수행 중인 상태이다. 이 상태에서는 중지된 모든 애플리케이션을 다시 시작시켜 서비스 가능한 상태로 만든다. resume 명령이 성공적으로 수행되면 서버는 RUNNING 상태가 된다. |
| SHUTTING_DOWN | 서버가 종료되고 있는 상태이다. deploy된 애플리케이션을 undeploy하고 부팅할 때 실행시켰던 JEUS 서비스들을 모두 종료시킨다. 서버를 종료할 때 적절한 타임아웃을 설정해서 서비스 중인 요청이 처리될 수 있도록 보장할 수 있다. 이를 Graceful Shutdown이라고 한다. |
참고
1. DAS에서 관리하는 MS의 Lifecycle에 대한 자세한 내용은 “JEUS Domain 안내서”의 “4.4. 서버 Lifecycle 상태 확인”을 참고한다.
2. Graceful Shutdown에 대한 자세한 내용은 “3.1.3. Managed Server 종료”를 참고한다.
JEUS 7부터 DAS와 MS는 기본적으로 Launcher를 통해 기동된다. 스크립트나 DAS를 통한 서버 실행 명령은 Launcher를 실행하게 되고, Launcher에서는 서버를 띄우기 위한 준비작업과 실제 서버를 기동하는 작업을 수행한다. Launcher에 대한 자세한 내용은 “1.6. Launcher”를 참고한다.
콘솔 툴이나 WebAdmin으로 DAS를 통해 서버를 시작하는 방법은 “JEUS Domain 안내서”의 “4.2.2. Managed Server(MS) 시작”을 참고한다.
본 절에서는 스크립트로 서버를 실행하는 예제만 설명한다.
예제
Launcher에서는 실제 서버의 JVM을 기동하고 해당 서버의 부팅이 완료된 것을 확인한 뒤에 종료된다. 다음과 같이 Launcher 로그를 통해 서버가 정상적으로 기동되었는지 확인할 수 있다.
JEUS_HOME/bin$ ./startManagedServer -domain domain1 -server server1 -u administrator -p adminadmin -dasurl 61.77.153.160:9736 *************************************************************** - JEUS Home : /home/test/jeus - JEUS Base Port : - Added Java Option : - Java Vendor : Sun *************************************************************** ... [2012.05.12 12:29:24][2] [launcher-1] [SERVER-0201] Successfully connected to the Domain Administration Server(61.77.153.160:9736). [2012.05.12 12:29:24][2] [launcher-1] [Launcher-0058] All local configurations are up-to-date. ... [2012.05.12 12:29:39][2] [server1-1] [SERVER-0248] The JEUS server is STARTING. [2012.05.12 12:29:39][2] [server1-1] [SERVER-0401] The elapsed time to start: 10500ms. [2012.05.12 12:29:39][2] [launcher-10] [Launcher-0034] The server[server1] initialization completed successfully[pid : 15432]. [2012.05.12 12:29:39][0] [launcher-1] [Launcher-0040] Successfully started the server. The server state is now RUNNING. JEUS_HOME/bin$
MS가 자신이 갖고 있는 애플리케이션 파일을 부팅 중 deploy할 때 문제가 발생할 경우 STANDBY 상태에 머무를 수 있다. MS가 부팅 중 deploy하는 애플리케이션은 보통 한 번 이상 정상적으로 서비스되던 것이다. 그렇기 때문에 이러한 문제가 발생했다면 이전과 비교하여 파일이 잘못 변경되었을 가능성이 크다.
특정 MS에서 JEUS 내부 디렉터리인 .workspace에 존재하는 애플리케이션의 xml 태그를 잘못 수정할 경우 아래와 같이 STANDBY 상태에 머무를 수 있다. 도메인 구조의 deploy에 대한 자세한 내용은 “JEUS Applications & Deployment 안내서”의 “제1장 도메인 환경에서 애플리케이션 관리”를 참고한다.
주의
애플리케이션의 관리는 DAS를 통해서 하는 것이 기본 정책이므로, MS의 .workspace 디렉터리에 직접 접근하여 작업하지 않도록 한다.
JEUS_HOME/bin$ ./startManagedServer -domain domain1 -server server1 -u administrator
-p adminadmin -dasurl 61.77.153.160:9736
...
[2012.05.12 17:12:48][2] [server1-1] [SERVER-0248] The JEUS server is STARTING.
[2012.05.12 17:12:48][2] [server1-1] [Deploy-0095] Distribute the application[de
ployment_helloear].
[2012.05.12 17:12:48][2] [server1-1] [SERVER-0201] Successfully connected to the
Domain Administration Server(61.77.153.160:9736).
[2012.05.12 17:12:48][0] [server1-1] [STDERR] java.lang.RuntimeException: Unexpe
cted close tag </application>; expected </module>
...
<<__!Exception__>>
[2012.05.12 17:12:48][1] [server1-1] [SERVER-0300] Distributing some registered
applications [deployment_helloear] failed.
[2012.05.12 17:12:48][2] [server1-1] [SERVER-0248] The JEUS server is STANDBY.
[2012.05.12 17:12:48][0] [server1-1] [SERVER-0250] Starting server (server1) fai
led. Staying in STANDBY.
[2012.05.12 17:12:48][2] [server1-1] [SERVER-0401] The elapsed time to start: 9541ms.
[2012.05.12 17:12:48][2] [launcher-10] [Launcher-0034] The server[server1] initi
alization completed successfully[pid : 31068].
[2012.05.12 17:12:48][0] [launcher-1] [Launcher-0042] Comp
leted starting the server but the server state is still STANDBY.
JEUS_HOME/bin$이 경우 다음과 같이 server-info 명령을 통해 MS가 STANDBY 상태임을 확인할 수 있다.
[DAS]domain1.adminServer>server-info
Information of Domain (domain1)
===============================================================================================
+--------+----------+-----+-------+-----+----------------+--------+-------------+-------------+
| Server | Status | Node| PID | Clus| Latest Start | Need to| Listen Ports| Running |
| | |Name | | ter |Time / Shutdown |Restart | | Engines |
| | | | | | Time | | | |
+--------+----------+-----+-------+-----+----------------+--------+-------------+-------------+
| adminSe| RUNNING | N/A | 2553 | N/A | Sat May 12 | false | base-61.77.1| jms, |
|rver(*) |(17175 | | | |12:26:41 KST | |53.160:9736 | ejb, web |
| |sec) | | | |2012 | | http-server-| |
| | | | | | | |0.0.0.0:8088 | |
+--------+----------+-----+-------+-----+----------------+--------+-------------+-------------+
| server1| STANDBY |node1| 31068 | N/A | Sat May 12 | N/A | base-61.77.1| jms, |
| |(96 sec) | | | |17:12:39 KST | |53.58:19736 | ejb, web |
| | | | | |2012 | | http-server-| |
| | | | | | | |0.0.0.0:18088| |
| | | | | | | |jms-internal-| |
| | | | | | | |0.0.0.0:19741| |
+--------+----------+-----+-------+-----+----------------+--------+-------------+-------------+
| server2| SHUTDOWN | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
+--------+----------+-----+-------+-----+----------------+--------+-------------+-------------+
===============================================================================================
MS의 종료는 jeusadmin 명령을 통해 가능하다. 특정 MS에 접속한 콘솔 툴에서 local-shutdown 명령을 통해 접속한 MS를 종료할 수도 있으며, 콘솔 툴이나 WebAdmin에서 DAS를 통한 명령으로 종료할 수도 있다. MS를 종료하는 방법에 대한 자세한 내용은 “JEUS Domain 안내서”의 “4.3.1. Managed Server(MS) 종료”를 참고한다.
참고
MS는 DAS의 관리를 받는 것이 기본 정책이므로 DAS를 통해 종료하는 것을 권장한다.
예제
MS를 종료할 때 현재 수행 중인 요청에 대한 처리를 보장해주는 Graceful Shutdown 기능이 존재한다. 서버 종료를 요청한 시점부터는 새로운 요청은 처리하지 않으나, 현재 수행 중인 요청에 대해서는 정해진 시간만큼 처리가 끝나길 기다려 줄 수 있다.
다음은 MS 종료 명령에 Timeout 옵션을 통해 대기시간을 설정하는 예제이다.
[DAS]domain1.adminServer>stop-server server1 -to 60000 Server [server1] was successfully stopped.
콘솔 툴을 통해 해당 MS에 직접 접속한 경우 역시 Timeout 지정이 가능하다.
domain1.server1>local-shutdown -to 60000 The server [server1] has been shut down successfully. offline>
정상적으로 종료된 서버에서는 다음과 같은 로그를 확인할 수 있다.
... [2012.05.12 18:03:04][2] [server1-63] [SERVER-0248] The JEUS server is SHUTDOWN. [2012.05.12 18:03:04][0] [server1-63] [SERVER-0265] The JEUS server has exited. [2012.05.12 18:03:04][0] [server1-1] [SERVER-0099] The server[server1] has been shut down. [2012.05.12 18:03:04][0] [server1-9] [SERVER-0565] The JVM process is shutting down. [2012.05.12 18:03:04][0] [server1-9] [SERVER-0566] The JVM process will be terminated.
MS의 종료는 애플리케이션 서비스를 모두 내리고 MS JVM을 종료하는 과정이다.
이와 달리 서비스하고 있던 모든 애플리케이션의 일시 정지 기능이 제공된다. 여기서도 마찬가지로 Graceful Timeout을 적용하여 현재 수행 중인 요청 처리 완료를 기다릴 수 있다. 콘솔 툴의 suspend-server 명령 또는 WebAdmin을 통해서 동작 가능하다.
WebAdmin 사용
다음은 WebAdmin을 통해 서버를 일시 정지하는 과정에 대한 설명이다.
-
WebAdmin의 왼쪽 메뉴에서 [Monitoring] > [Servers]를 선택하면 도메인 서버 목록이 조회된다. 목록에서 일시 정지할 서버의 이름 옆에 있는 체크박스를 체크한 뒤 [suspend] 버튼을 클릭한다.
-
동작이 완료된 후 다음과 같이 일시 정지가 되었는지 여부를 확인할 수 있다.
콘솔 툴 사용
다음은 콘솔 툴을 통해 서버를 일시 정지하는 예제이다.
[DAS]domain1.adminServer>suspend-server -servers server1 -to 60000
Successfully suspended server(s).
server-info 명령으로 서버가 SUSPENDED 상태가 된 것을 확인할 수 있다.
[DAS]domain1.adminServer>server-info Information of Domain (domain1) ================================================================================================ +--------+------------+-----+------+-----+----------------+--------+-------------+-------------+ | Server | Status | Node| PID | Clus| Latest Start | Need to| Listen Ports| Running | | | |Name | | ter |Time / Shutdown |Restart | | Engines | | | | | | | Time | | | | +--------+------------+-----+------+-----+----------------+--------+-------------+-------------+ | adminSe| RUNNING | N/A | 2553 | N/A | Sat May 12 | false | base-61.77.1| jms, | |rver(*) |(21406 | | | |12:26:41 KST | |53.160:9736 | ejb, web | | |sec) | | | |2012 | | http-server-| | | | | | | | | |0.0.0.0:8088 | | +--------+------------+-----+------+-----+----------------+--------+-------------+-------------+ | server1| SUSPENDED |node1| 658 | N/A | Sat May 12 | N/A | base-61.77.1| jms, | | |(3 sec) | | | |18:24:02 KST | |53.58:19736 | ejb, web | | | | | | |2012 | | http-server-| | | | | | | | | |0.0.0.0:18088| | | | | | | | | |jms-internal-| | | | | | | | | |0.0.0.0:19741| | +--------+------------+-----+------+-----+----------------+--------+-------------+-------------+ | server2| SHUTDOWN | N/A | N/A | N/A | N/A | N/A | N/A | N/A | +--------+------------+-----+------+-----+----------------+--------+-------------+-------------+ ================================================================================================
정상적으로 일시 정지된 서버에서는 다음과 같은 로그를 확인할 수 있다.
[2012.05.12 18:24:51][2] [server1-30] [SERVER-0248] The JEUS server is SUSPENDING.
...
[2012.05.12 18:24:51][2] [server1-30] [EJB-4953] [deployment_helloear#ejb] The EJB
module stopped.
[2012.05.12 18:24:51][2] [server1-30] [WEB-3485] ServletContext[name=deployment_
helloear#web, path=/hello, ctime=Sat May 12 18:24:15 KST 2012] stopped successfully.
[2012.05.12 18:24:51][2] [server1-30] [SERVER-0248] The JEUS server is SUSPENDED.
참고
DAS의 제어를 받지 않고 있는 경우에도 해당 서버에 직접 콘솔 툴에 접속하여 MS를 일시 정지시킬 수 있다.
일시 정지되었던 서버의 애플리케이션들을 다시 서비스하도록 복귀시킬 수 있다.
WebAdmin 사용
다음은 WebAdmin을 통해 서버를 복귀시키는 과정에 대한 설명이다.
-
WebAdmin의 왼쪽 메뉴에서 [Monitoring] > [Servers]를 선택하면 도메인 서버 목록이 조회된다. 목록에서 서비스를 다시 시작할 서버의 이름 옆에 있는 체크박스를 체크한 뒤 [resume] 버튼을 클릭한다.
-
동작이 완료된 후 다음과 같이 서버가 정상적으로 resume되었는지 여부를 확인할 수 있다.
콘솔 툴 사용
DAS의 제어를 받지 않고 있는 경우에도 해당 서버에 직접 콘솔 툴에 접속하여 SUSPENDED 상태인 MS를 다시 시작시킬 수 있다.
다음은 콘솔 툴을 통해 서버를 복귀시키는 예제이다.
[DAS]domain1.adminServer>resume-server -servers server1
Successfully resumed the servers.
server-info 명령을 통해 서버가 다시 RUNNING 상태가 된 것을 확인할 수 있다.
[DAS]domain1.adminServer>server-info Information of Domain (domain1) ============================================================================================== +--------+----------+-----+------+-----+---------------+---------+-------------+-------------+ | Server | Status | Node| PID | Clus| Latest Start | Need to | Listen Ports| Running | | | |Name | | ter |Time / Shutdown| Restart | | Engines | | | | | | | Time | | | | +--------+----------+-----+------+-----+---------------+---------+-------------+-------------+ | adminSe| RUNNING | N/A | 2553 | N/A | Sat May 12 | false | base-61.77.1| jms, | |rver(*) |(21420 | | | |12:26:41 KST | |53.160:9736 | ejb, web | | |sec) | | | |2012 | | http-server-| | | | | | | | | |0.0.0.0:8088 | | +--------+----------+-----+------+-----+---------------+---------+-------------+-------------+ | server1| RUNNING |node1| 658 | N/A | Sat May 12 | false | base-61.77.1| jms, | | |(1 sec) | | | |18:24:02 KST | |53.58:19736 | ejb, web | | | | | | |2012 | | http-server-| | | | | | | | | |0.0.0.0:18088| | | | | | | | | |jms-internal-| | | | | | | | | |0.0.0.0:19741| | +--------+----------+-----+------+-----+---------------+---------+-------------+-------------+ | server2| SHUTDOWN | N/A | N/A | N/A | N/A | N/A | N/A | N/A | +--------+----------+-----+------+-----+---------------+---------+-------------+-------------+ ==============================================================================================
정상적으로 애플리케이션 서비스가 다시 시작된 서버에서는 다음과 같은 로그를 확인할 수 있다.
[2012.05.12 18:25:07][2] [server1-30] [SERVER-0248] The JEUS server is RESUMING.
[2012.05.12 18:25:07][2] [server1-30] [Deploy-0098] Starting the application
[deployment_helloear].
[2012.05.12 18:25:07][2] [server1-30] [EJB-4952] [deployment_helloear#ejb]
The EJB module started.
[2012.05.12 18:25:07][2] [server1-30] [WEB-3484] ServletContext[name=deployment_
helloear#web, path=/hello, ctime=Sat May 12 18:24:15 KST 2012] started
successfully.
[2012.05.12 18:25:07][2] [server1-30] [Deploy-0099] Successfully started the
application[deployment_helloear].
[2012.05.12 18:25:07][2] [server1-30] [SERVER-0248] The JEUS server is RUNNING.
JEUS 서버에는 애플리케이션을 서비스하는 엔진이 내부적으로 존재한다. 웹 애플리케이션 서비스, EJB 애플리케이션 서비스, JMS 서비스를 위한 엔진이 각각 존재한다. 이들 각 엔진의 사용 여부는 초기화 시점을 설정을 통해 제어할 수 있다. 단, 현재 이들 설정은 모두 서버를 재기동해야 적용된다.
JEUS 서버의 각 엔진의 사용 여부를 설정한다. 각 엔진에 대하여 사용 설정을 할 경우 각 엔진들은 엔진 초기화와 동시에 각 엔진에서 서비스될 첫 번째 애플리케이션이 deploy될 때 필요한 엔진이 초기화된다. 사용 설정을 하지 않은 경우 서버가 기동된 후에도 엔진은 초기화되지 않으므로 해당 엔진에서 서비스될 애플리케이션들을 deploy하면 실패하게 된다.
경고
엔진 사용가능할 때 정상적으로 deploy된 애플리케이션을 이후 엔진 미사용을 한 후 서버를 기동할 경우 해당 애플리케이션은 deploy 실패하게된다. 그리고 서버의 상태도 서비스 가능상태(RUNNING)가 아닌 대기(STANDBY)로 전환됨으로 관리자가 이를 확인하여 엔진의 상태와 애플리케이션의 상태를 수정해주어야한다.
WebAdmin과 콘솔 툴로 각 엔진별 사용 여부를 설정할 수 있다.
WebAdmin 사용
WebAdmin의 왼쪽 메뉴에서 [Servers]에서 원하는 서버를 선택하면 선택하면 해당 서버의 설정을 확인할 수 있다. 이 화면 중간에 각 엔진들의 사용 여부를 설정한 부분이 있다.
[LOCK & EDIT] 버튼을 클릭한 후 설정을 변경할 엔진 정보를 설정하고 [확인] 버튼을 클릭한다. [Activate Changes] 메뉴를 선택해서 설정 정보를 적용하려면 서버를 재시작해야 한다.
콘솔 툴 사용
콘솔 툴에서 서버 내 각 엔진 사용 여부를 설정하는 방법은 다음과 같다.
[DAS]domain1.adminServer>disable-engines adminServer -all All engine(s) was(were) successfully disabled. The configuration was changed. ================================================================================ +------------------------------------------------------------------------------+ | Result | +------------------------------------------------------------------------------+ | Successfully changed only the XML. | | Restart the server to apply the changes. | +------------------------------------------------------------------------------+ ================================================================================ ... [DAS]domain1.adminServer>disable-engines adminServer -web -ejb Web EJB engine(s) was(were) successfully disabled. The configuration was changed. ================================================================================ +------------------------------------------------------------------------------+ | Result | +------------------------------------------------------------------------------+ | Successfully changed only the XML. | | Restart the server to apply the changes. | +------------------------------------------------------------------------------+ ================================================================================ ... [DAS]domain1.adminServer>disable-engines adminServer -all All engine(s) was(were) successfully enabled. The configuration was changed. ================================================================================ +------------------------------------------------------------------------------+ | Result | +------------------------------------------------------------------------------+ | Successfully applied part of the changes. | | Restart the server to apply the remaining changes. | +------------------------------------------------------------------------------+ ================================================================================ ... [DAS]domain1.adminServer>disable-engines adminServer -web -ejb Web EJB engine(s) was(were) successfully enabled. The configuration was changed. ================================================================================ +------------------------------------------------------------------------------+ | Result | +------------------------------------------------------------------------------+ | Successfully applied part of the changes. | | Restart the server to apply the remaining changes. | +------------------------------------------------------------------------------+ ================================================================================
참고
JEUS 콘솔 툴의 서버 내 엔진 설정 명령에 대한 자세한 정보는 “JEUS Reference Book”의 “4.2.3.9. disable-engines”, “JEUS Reference Book”의 “4.2.3.15. enable-engines”를 참고한다.
JEUS 서버의 각 엔진의 사용 여부를 설정한다. 각 엔진에 대하여 사용 설정을 할 경우 각 엔진들은 엔진 초기화와 동시에 또는 각 엔진에서 서비스될 첫 번째 애플리케이션이 deploy될 때 필요한 엔진이 초기화된다. 사용 설정을 하지 않은 경우 서버가 기동된 후에도엔진은 초기화되지 않으므로 해당 엔진에서 서비스될 애플리케이션들을 deploy할 경우 실패하게 된다.
WebAdmin과 콘솔 툴로 각 엔진별 사용 여부를 설정할 수 있다.
WebAdmin 사용
WebAdmin의 왼쪽 메뉴에서 [Servers]에서 서버를 선택하면 해당 서버의 설정을 확인할 수 있다. 이 화면 중간에 각 엔진들의 서버를 기동할 때 초기화 여부를 설정한 부분이 있다.
[LOCK & EDIT]를 클릭한 후 설정을 변경할 엔진에 맞추어 설정한 후 [확인] 버튼을 클릭한다. [Activate Changes] 메뉴를 선택해서 설정 정보를 적용하려면 서버를 재시작해야 한다. 화면은 엔진 사용 여부 설정 확인 화면과 같은 화면이므로 위 화면을 참고한다.
콘솔 툴 사용
콘솔 툴에서 서버 내 각 엔진의 초기화 시점을 설정하는 방법은 다음과 같다.
[DAS]domain1.adminServer>disable-engine-init-on-boot adminServer,server1 EngineInitOnBoot was successfully enabled. The configuration was changed. ================================================================================ +------------------------------------------------------------------------------+ | Result | +------------------------------------------------------------------------------+ | Successfully changed only the XML. | | Restart the server to apply the changes. | +------------------------------------------------------------------------------+ ================================================================================ [DAS]domain1.adminServer>enable-engine-init-on-boot adminServer EngineInitOnBoot was successfully enabled. The configuration was changed. ================================================================================ +------------------------------------------------------------------------------+ | Result | +------------------------------------------------------------------------------+ | Successfully applied part of the changes. | | Restart the server to apply the remaining changes. | +------------------------------------------------------------------------------+ ================================================================================
참고
JEUS 콘솔 툴의 서버 내 엔진 설정 명령에 대한 자세한 정보는 “JEUS Reference Book”의 “4.2.3.8. disable-engine-init-on-boot”, “JEUS Reference Book”의 “4.2.3.14. enable-engine-init-on-boot”를 참고한다.
JEUS에서는 서블릿 Thread와 EJB 리모트 Thread, System Thread Pool에 대한 모니터링 기능과 Thread의 Stack을 확인할 수 있는 기능, 그리고 특정 Thread에 Interrupt Signal을 보낼 수 있는 기능을 제공한다.
JEUS에서는 Thread를 모니터링하는 기능을 제공한다. 모니터링의 대상이 되는 Thread는 서블릿 Thread, EJB 리모트 요청 Thread 그리고 System Thread Pool이다.
서블릿 Thread나 EJB 리모트 요청 Thread의 모니터링 기능을 사용하면 Thread ID, Thread 이름, Thread 상태, 처리시간 등의 정보를 알 수 있고 Thread Pool 모니터링 기능을 사용하면 System Thread Pool의 core size, max size, keep alive time 그리고 System Thread Pool에 있는 Thread 정보를 알 수 있다.
단, 콘솔 툴에서는 서블릿 Thread와 EJB 리모트 요청 Thread만 모니터링할 수 있다.
Thread 정보 확인
WebAdmin과 콘솔 툴로 Thread 정보를 확인할 수 있다.
-
WebAdmin 사용
WebAdmin의 왼쪽 메뉴에서 [Monitoring] > [Thread]를 선택하면 Thread 모니터링 화면으로 이동한다.
Thread 정보를 조회할 서버의 이름을 선택하면 다음과 같이 Thread들에 대한 정보를 확인할 수 있다.
-
콘솔 툴 사용
콘솔 툴에서 Thread 정보를 확인하는 방법은 다음과 같다.
[DAS]domain1.adminServer>thread-info -server adminServer Thread information for the server [adminServer] There are no EJB RMI threads for the server [adminServer]. ============================================================ The web container threads for 'ADMIN-HTTP' listener. +-----+--------------------------+---------+---------+-----+ | tid | name | state | elapsed | uri | +-----+--------------------------+---------+---------+-----+ | 48 | ADMIN-HTTP-2 | waiting | 21050 | | +-----+--------------------------+---------+---------+-----+ elapsed: Elapsed time (ms) ============================================================ ================================================================================ Thread statistics for the 'ADMIN-HTTP' listener. +-----------------------------------+-------+--------+------+---------+--------+ | | total | active | idle | blocked | reconn | +-----------------------------------+-------+--------+------+---------+--------+ | The number of threads. | 1 | 0 | 1 | 0 | 0 | +-----------------------------------+-------+--------+------+---------+--------+ total = active + idle, reconn: reconnecting ================================================================================ ====================================================== The web container threads for 'http1' listener. +-----+--------------------+---------+---------+-----+ | tid | name | state | elapsed | uri | +-----+--------------------+---------+---------+-----+ | 49 | http1-1 | waiting | 21018 | | | 50 | http1-10 | waiting | 21018 | | | 51 | http1-2 | waiting | 21018 | | | 52 | http1-3 | waiting | 21018 | | | 53 | http1-4 | waiting | 21018 | | | 54 | http1-5 | waiting | 21017 | | | 55 | http1-6 | waiting | 21014 | | | 56 | http1-7 | waiting | 21014 | | | 57 | http1-8 | waiting | 21013 | | | 58 | http1-9 | waiting | 21013 | | +-----+--------------------+---------+---------+-----+ elapsed: Elapsed time (ms) ====================================================== ================================================================================ Thread statistics for the 'http1' listener. +-----------------------------------+-------+--------+------+---------+--------+ | | total | active | idle | blocked | reconn | +-----------------------------------+-------+--------+------+---------+--------+ | The number of threads. | 10 | 0 | 10 | 0 | 0 | +-----------------------------------+-------+--------+------+---------+--------+ total = active + idle, reconn: reconnecting ================================================================================
특정 Thread의 Stack Trace 조회
WebAdmin과 콘솔 툴로 특정 Thread의 Stack Trace를 조회할 수 있다.
-
WebAdmin 사용
WebAdmin의 Thread 모니터링 화면에서 특정 tid를 클릭하면 해당 Thread의 Stack Trace를 조회할 수 있다.
다음은 WebAdmin에서 특정 Thread의 Stack Trace를 조회한 화면이다.
-
콘솔 툴 사용
콘솔 툴에서 특정 Thread의 Stack Trace를 조회하는 방법이다. 주로 Thread 정보를 조회하는 명령(콘솔 툴에서의 ti 명령)을 통해 확인했을 때 블록된 Thread가 있을 경우 해당 Thread의 Stack을 확인하는 데 사용한다.
[DAS]domain1.adminServer>print-stack-trace -server server1 45 servlet thread [tid=45] Stack trace of ADMIN-HTTP-1 [server1-45] tid=45 java.lang.Thread.State: WAITING at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject .await(AbstractQueuedSynchronizer.java:1987) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at jeus.util.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1291) at jeus.servlet.engine.WebThreadPoolExecutor.getTask(WebThreadPoolExecutor.java:68) at jeus.util.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:1215) at jeus.servlet.engine.WebThreadPoolExecutor$WebRequestWorker. run(WebThreadPoolExecutor.java:332) at java.lang.Thread.run(Thread.java:662)
참고
1. JEUS 콘솔 툴의 ti 명령과 strace 명령에 대한 자세한 정보는 “JEUS Reference Book”의 “4.2.2. Local 명령어”를 참고한다.
2. 서블릿 Thread와 EJB 리모트 요청 Thread 정보, Stack Trace는 WebAdmin의 [Monitoring] > [Thread] 메뉴에서 확인할 수 있다. 또한 System Thread Pool의 정보와 System Thread Pool의 Thread 정보를 확인할 수 있다. 더 자세한 사항은 "JEUS WebAdmin 안내서"와 온라인 도움말을 참고한다.
JEUS에서는 특정 Thread에 Interrupt Signal을 보내서 수행 중인 작업을 중단할 수 있도록 Exception을 발생시키는 기능이 있다.
주의
이 기능은 현재 실험적으로 제공되는 기능으로 Thread에 Interrupt가 걸려 있으면 수행 중인 Thread가 바로 중단되는 것이 아니라 Interrupt Status를 체크하여 Exception을 던져 더 이상 진행하지 않도록 유도하는 것이기 때문에 발생하는 Exception에 대해서는 사용자 애플리케이션에서 처리해야 한다. Exception을 제대로 처리하지 않아서 발생하는 문제에 대해서는 사용자에게 책임이 있다.
Thread Interrupt
Thread에 Interrupt를 건다는 것은 동작하고 있는 Thread에 Interrupt Signal을 보내서 현재 진행 중인 동작의 중단을 유도하기 위해 Exception을 발생시켜 이후의 작업을 더 이상 진행하지 않도록 힌트를 주는 것이다. 주로 요청이 블록되어 있거나, 예상한 시간보다 오래 지체되어 있는 경우에 사용될 수 있다.
실제로 Thread에 Interrupt가 걸린다고 해서 해당 Thread가 강제적으로 멈춘다든가, Interrupt를 발생시키는 순간에 바로 효과가 있는 것은 아니다.
JEUS에서는 서블릿 Thread, EJB 리모트 요청 Thread와 System Thread Pool의 수행 중인 Thread에 Interrupt Signal을 보낼 수 있는 기능을 지원한다. 이때 Thread가 JNDI 원격 커넥션이나 EJB operation, JDBC operation, 또는 I/O 작업을 진행 중이면 Interrupt가 걸릴 수 있다.
-
서블릿 Thread
서블릿 Thread는 다음의 경우들에 대해 Interrupt가 걸려 있으면 Exception이 발생한다. 이때 발생하는 Exception에 대한 처리는 사용자 애플리케이션에서 해야 한다.
-
JNDI 원격 커넥션을 맺으려고 할 때
-
JNDI 원격 operation을 수행하려고 할 때
-
EJB 호출하려고 할 때
-
JDBC 커넥션을 얻어올 때 또는 커넥션 객체의 메소드를 호출할 때
콘솔 툴이나 WebAdmin을 통해 관리자가 직접 Interrupt를 걸 수 있으며, 서블릿 Thread의 수행시간을 체크하여 자동으로 Interrupt 되도록 하는 기능을 제공한다. 이 기능에 대한 설정 방법은 “JEUS Web Engine 안내서”의 “2.3.7. 자동 Thread Pool 관리 설정(Thread 상태 통보)”을 참고한다.
-
-
EJB 리모트 요청 Thread
EJB operation의 경우에는 다음의 시점에 Interrupt Status를 체크해서 javax.ejb.EJBException을 발생시킨다.
-
EJB 2.x 방식으로 create와 같은 EJBHome 메소드를 호출할 때(EJB 3.0의 경우 사용자가 EJB Lookup을 하면 EJB 컨테이너 내부적으로 create 처리)
-
EJB 비즈니스 메소드를 호출할 때
이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해주어야 한다. 만약 EJB 비즈니스 메소드 호출이 이미 들어간 상태에서 Interrupt Signal을 받았다면 Exception이 발생하지 않을 수 있다. 하지만 해당 메소드에서 다른 EJB를 호출한다던가, JDBC operation이나 JNDI operation을 사용하는 경우라면 Interrupt가 걸릴 수도 있다.
-
-
JDBC
JDBC operation의 경우에는 다음의 operation을 수행하려고 할 때 Interrupt Signal을 받았다면 java.sql.SQLException이 발생한다. 이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해주어야 한다.
-
DataSource#getConnection()을 통해 Connection Pool에서 커넥션을 가져올 때
-
Connection Pool에서 가져온 java.sql.Connection에 대해서 operation을 수행하려고 할 때
-
JDBC Connection Pool 설정에 use-sql-trace나 stmt-caching-size 옵션을 설정하고 executeQuery와 같은 operation을 수행하려고 할 때(옵션에 대한 자세한 설명은 “6.4.2. Connection Pool 설정”을 참고한다.)
-
-
JNDI
JNDI operation을 수행하는 중에도 Interrupt의 효과가 있는 경우가 있다. 다음의 JNDI operation을 수행하려고 할 때 Interrupt Signal을 받았다면 javax.naming.NamingException이 발생한다. 이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해주어야 한다.
-
JNDI 원격 커넥션을 맺을 때(javax.naming.InitialContext를 생성하는 시점)
-
JNDI operation을 하기 위해 원격 메시지를 보낼 때
Lookup, Bind, Rebind, Rename과 같은 JNDI operation일 경우이다. 단, 로컬(같은 JVM)에 있는 레지스트리에 접근하거나 캐시에 접근하는 경우에는 Interrupt의 효과가 없다.
-
-
I/O 작업
I/O 작업을 할 때는 항상은 아니지만 상황에 따라 Interrupt의 효과가 있을 수 있다.
-
java.nio.channels.SocketChannel
java.nio.channels.SocketChannel을 사용하는 경우에는 Interrupt에 걸리게 된다. java.nio.channels.SocketChannel을 사용해서 연결할 때는 3단계로 분리된다.
첫 번째 단계인 begin 단계에서는 Thread에 Interrupt Status가 설정되었는지 체크하고 설정되어 있다면 채널을 종료한다. 실제 연결하는 단계에서는 Interrupt Status가 설정되어 있다면 connect()를 진행하지 않고, end 단계에서 Interrupt가 걸려 있다면 java.nio.channels.ClosedByInterruptedException이 발생한다(이후에 Interrupt Status는 clear된다).
-
java.nio.channels.SocketChannel#read()/java.nio.channels.SocketChannel#write()
java.nio.channels.SocketChannel#read()나 java.nio.channels.SocketChannel#write()하는 경우에도 역시 3단계로 나뉘게 된다.
첫 번째 단계인 begin 단계에서는 Interrupt Status가 설정되었는지 체크하고 설정되어 있다면 채널을 종료한다. 그리고 실제 IO를 처리하는 단계에서는 Interrupt Status가 설정되어 있다면 실제 Read, Write를 진행하지 않고 마지막 end 단계에서는 java.nio.channels.ClosedByInterruptedException이 발생한다(이후에 Interrupt Status는 clear된다).
java.nio.channels.ClosedByInterruptedException이 발생한 후 이전에 생성했던 채널을 사용해서 Read, Write를 하려고 하면 I/O 작업이 수행되지 않고 java.nio.channels.ClosedChannelException이 발생한다.
-
java.net.Socket 사용
java.net.Socket을 사용할 때는 OS, JVM에 따라서 다르다. HP-UX와 Solaris에서는 JVM의 컴파일 옵션에 따라 Socket I/O 작업에 Interrupt를 걸 수 있다.
Socket의 스트림을 통해 Read나 Write를 하려고 할 때 Interrupt Status가 체크되기 때문에 Interrupt에 걸릴 수 있고 java.net.SocketException이 발생한다(이후에 Interrupt Status는 clear된다). 하지만 이때 실제 소켓이 끊어지는 것은 아니고 Interrupt가 걸린 시점의 다음 operation만 중단된다(다음에 Read, Write를 수행하면 제대로 동작한다).
그 외 Windows, IBM AIX, Linux 등에서는 Socket I/O 작업을 하는 Thread에 Interrupt를 걸어도 효과가 없다.
-
-
Object#wait() / Thread#sleep() / Thread#join()
Thread가 Object#wait(), Thread#sleep() 또는 Thread#join()하고 있는 상태라면 해당 Thread는 Interrupt에 걸리게 된다. 이 경우 해당 Thread는 java.lang.InterruptedException이 발생한다(이후에 Interrupt Status는 clear된다).
참고
자세한 사항은 해당 클래스의 Javadoc API 문서를 참고한다.
Interrupt Signal 전송
JEUS에서는 콘솔 툴과 WebAdmin을 통해 Thread에 Interrupt Signal을 보낼 수 있는 명령을 제공한다.
-
WebAdmin 사용
Thread 모니터링 화면에서 [interrupt] 버튼을 클릭하면 해당 Thread에 Interrupt Signal을 보낼 수 있다.
-
콘솔 툴 사용
다음은 콘솔 툴 사용해서 Thread Interrupt Signal을 전송하는 예제이다. JEUS 콘솔 툴의 interrupt-thread 명령에 대한 자세한 정보는 “JEUS Reference Book”의 “4.2.5.1. interrupt-thread”를 참고한다.
[DAS]domain1.adminServer>interrupt-thread -server server1 45 Sent an interrupt hint signal to the thread [tid=45] on the server server1.
JEUS에서는 메모리를 모니터링하고 특정 사용량을 초과한 경우에 서버를 제어할 수 있는 기능을 제공한다.
WebAdmin과 콘솔 툴을 사용해서 메모리 정보를 확인할 수 있다.
WebAdmin 사용
다음은 WebAdmin을 사용해서 메모리 정보를 확인하는 방법이다.
참고
WebAdmin을 통해서 메모리 정보를 확인하는 방법은 [Monitoring]의 [Web] 메뉴를 사용하거나 [System Info] 메뉴를 사용하는 방법이 있다. [System Info] 메뉴에서는 메모리 정보뿐만 아니라 CPU, Process, JVM 정보까지 모두 확인이 가능하고, [Web] 메뉴에서는 간단한 메모리 정보를 확인할 수 있다. 그러므로 본 절에서는 [System Info] 메뉴를 사용한 방법을 설명한다.
-
WebAdmin의 왼쪽 메뉴에서 [Monitoring] > [System Info]를 선택하면 메모리를 포함한 시스템 전반적인 모니터링 화면으로 이동한다.
-
조회할 서버 이름을 클릭하면 다음과 같이 메모리 정보를 확인할 수 있다.
콘솔 툴 사용
콘솔 툴에서 memory-info 명령을 사용하여 메모리 정보를 확인할 수 있다. memory-info 명령에 대한 자세한 내용은 “JEUS Reference Book”의 “4.2.3. Server Management 관련 명령어”를 참고한다.
[DAS]domain1.adminServer>memory-info -servers adminServer
Domain [domain1] Memory Information
Memory Information
================================================================================
+-------------+---------------------------+------------------------------------+
| Server | Total Amount of Memory | The Current Amount of Memory |
+-------------+---------------------------+------------------------------------+
| adminServer | 177274880 | 101567168 |
+-------------+---------------------------+------------------------------------+
================================================================================
JEUS에서는 자주 사용되는 기능은 아니기 때문에 현재 시스템 프로퍼티를 통해서만 메모리 관련 동작을 제어할 수 있다.
참고
1. Memory Overflow가 발생한 경우 오직 한 번 Heap Dump를 떨어뜨리게 되어 있다. (SERVER_HOME/logs 디렉터리에 생성)
2. IBM JDK의 경우에는 Java를 실행한 위치에 Heap Dump가 떨어지므로 경로를 다르게 설정하려면 -Xdump:heap:file 옵션을 사용해야 한다. IBM Heap Dump에 대한 더 많은 옵션은 관련 홈 페이지를 참조한다.
관련된 프로퍼티는 다음과 같다.