[Web Application Server] Thread State Notify 설정 가이드

본 포스팅은 JEUS Thread State Notiry 설정 가이드입니다.

---

thread-state-notify 설정은 다음과 같은 의미를 갖고 있습니다.

thread-state-notify 설정은 Thread의 최대 수행 시간을 정함으로써 Thread Hang으로 인한 서비스의 중단을 방지하는 것을 목적으로 합니다.

Thread의 수행 시간을 주기적으로 체크하여 최대 수행 시간을 넘기는 Thread에 한하여 강제로 Block시키고 삭제할 수 있으며 Blocked Thread의 수가 일정 비율을 넘기면 Container restart를 수행할 수 있습니다.

 

주의할 점은 Thread의 상태를 모니터링 하는 주기는 WEBMain.xml의 monitoring 태그에서 정한다는 것입니다. monitoring 태그를 설정하지 않고 thread-state-notify 설정만 했을 경우 Thread의 수행 시간을 manager가 체크하지 않기 때문에 원하는 결과를 얻을 수 없습니다.

 

해당 설정의 자세한 설명은 아래에서 시나리오 #1, #2, #3으로 나누어 설명하겠습니다.

시나리오 #1. max-thread-active-time를 10초로 설정하였을 경우 다음과 같이 동작합니다.

Thread의 최대 수행시간(max-thread-active-time)을 10초로 설정하고 JSP를 수행하였을 경우를 그림으로 표시했습니다. 그림에서 보면 JSP가 수행 후 Running 상태가 되었다가 10초가 경과하면서 Blocked 상태가 되는 것을 확인 할 수 있습니다. 이때 Blocked 된 Thread를 대신할 신규 Thread가 생성되는 것도 확인 할 수 있습니다. 이러한 수행이 계속되면서 10초 이상 수행되는 Thread들은 Blocked 상태가 되고 신규 Thread를 생성함으로써 가용할 수 있는 Thread의 개수가 일정하게 유지됩니다.

시나리오 #2. max-thread-active-time를 10초로 설정하고, thread-interrupt-execution을 true로 설정하였을 경우 다음과 같이 동작합니다.

Thread의 최대 수행시간(max-thread-active-time)을 10초, thread-interrupt-execution을 true로 설정하고 JSP를 수행하였을 경우를 표시했습니다. 그림에서 보면 JSP가 수행 후 Running 상태가 되었다가 10초가 경과하면서 Blocked 상태가 되는 것을 확인할 수 있습니다. 이때 일반적인 JSP의 경우와 소켓 통신 중인 JSP 두 가지 경우로 나뉘는데 일반적인 JSP를 수행하는 경우는 해당 Thread가 Blocked되고 uri가 unknown으로 변한 후 바로 Thread가 삭제됩니다.

하지만 소켓 통신 중인 JSP를 수행하는 경우는 해당 Thread가 Blocked되지만 uri는 수행되는 AP가 계속 표시되며 Thread의 삭제가 이루어지지 않습니다. 이러한 차이를 보이는 이유는 thread-interrupt-execution 설정이 true인 경우 Blocked 상태가 된 Thread에 manager가 interrupt 신호를 보내 Thread의 삭제를 시도하게 되는데 소켓 통신의 경우 interrupt 신호로 인한 Exception이 쉽게 발생하지 않아 삭제를 수행하지 못하기 때문입니다.

<주의사항>

소켓통신 중 JSP의 경우 Blocked 상태에서 삭제가 이루어지지 않기 때문에 Thread를 계속 물고 있습니다. 이때 WebtoB와의 연결도 계속 물려있기 때문에 WebtoB와 JEUS 사이의 Thread 개수가 같을 경우 신규 생성 된 Thread는 reconnecting 상태가 되므로 WebtoB의 Thread 개수를 더 많이 주어야 합니다.

시나리오 #3. max-thread-active-time를 10초로 설정하고, restart-threshold-ratio를 0.5초로 설정하였을 경우 다음과 같이 동작합니다.

Thread의 최대 수행시간(max-thread-active-time)을 10초, restart-threshold-ratio을 0.5로 설정하고 JSP를 수행하였을 경우를 표시했습니다. 그림에서 보면 2개의 JSP가 수행 후 Running 상태가 되었다가 10초가 경과하면서 Container가 restart하는 것을 확인할 수 있습니다. restart-threshold-ratio 값을 전체 Thread를 50%로 정하였기 때문에 4개의 Thread 중 2개의 Thread가 수행하다 Blocked로 빠지는 즉시 Container Restart가 이루어지는 것입니다.

이 비율은 WEBMain.xml에 설정한 Thread의 max값을 기준으로 하기 때문에 Blocked 상태의 Thread로 인해 생기는 신규 Thread와는 별개로 산정됩니다. 즉 min값이 4개이고 max가 10개일 경우 restart 비율을 50%로 설정하면 기준 값이 Thread 5개가 되며 중간에 신규 Thread가 생기더라도 Blocked 된 Thread가 5개가 되는 시점에 Container restart가 이루어집니다.

다음으로 실제 테스트수행 과정에 대해 살펴보겠습니다.

먼저 환경 설명입니다.

sleep.jsp는 Thread Hang 상태를 만들기 위하여 Thread.sleep를 포함하고 있습니다.

urlconnection.jsp는 Socket 통신 중에 Hang이 발생한 Thread을 만들기 위하여 사용합니다.

sleep.jsp를 socket 통신으로 read 하므로 원격지에서 응답이 없어 Thread Hang이 발생하도록 구성 후 테스트를 수행합니다.

테스트 수행과정입니다.

a. Thread block 테스트는 다음과 같이 진행하였습니다.

check-thread-pool 5초, max-thread-active-time 10초 설정 후 sleep.jsp 테스트를 수행합니다.

sleep.jsp가 수행 된 후 10초가 지나면서 blocked 상태로 변하고 신규 Thread가 생성되는 것을 Thread 상태에서 확인 할 수 있습니다. JEUS Server log에서도 Thread가 blocked로 변하고 신규 Thread가 생성되는 과정을 확인 할 수 있습니다.

b. Blocked Thread 삭제 후 일반 JSP 호출 테스트는 다음과 같이 진행하였습니다.

a번 설정에서 thread-interrupt-execution 추가 후 sleep.jsp 테스트를 수행합니다.

sleep.jsp가 수행 된 후 10초가 지나면서 blocked 상태로 변하고 신규 Thread가 생성되는 것을 Thread 상태에서 확인 할 수 있습니다. 이때 blocked 상태로 변한 Thread는 interrupt 신호를 받고 Exception을 발생시키며 삭제되는 것을 JEUS Server log에서 확인할 수 있습니다.

c. Blocked Thread 삭제 후 Socket 통신 중인 jsp 수행 테스트는 다음과 같이 진행하였습니다.

a번 설정에서 thread-interrupt-execution 추가 후 urlconnection.jsp 테스트를 수행합니다.

urlconnection.jsp가 수행 된 후 10초가 지나면서 blocked 상태로 변하고 신규 Thread가 생성되는 것을 Thread 상태에서 확인 할 수 있습니다. 이때 blocked 상태로 변한 Thread는 2)번의 sleep.jsp 실행 시와 같이 interrupt 신호를 받지만 interrupt Exception을 발생시키지 못하고 계속 Thread Pool에 남아 있는 것을 확인할 수 있습니다.

해당 Thread는 300초가 지난 후에 삭제 되었습니다.

d. Container restart 테스트는 다음과 같이 진행하였습니다.

a번 설정에서 restart-engine-execution과 restart-threshold-ratio를 0.5(50%)로 설정하고 urlconnection.jsp 테스트를 수행합니다.

active 중인 w02 Thread가 10초 이상 수행되면서 Blocked 됩니다.

이로 인해 Blocked 된 Thread가 전체의 50%(총 4개 중 2개 – w00, w02)넘기면서 restart하는 조건에 만족하여 해당 Container가 Thread dump를 남기고 restart하게 됩니다.

일반적인 운영상황에서 발생할 수 있는 Thread Leak에 대한 대처 방법으로 사용이 가능합니다. Thread의 수행 시간을 주기적으로 체크하여 최대 수행 시간을 넘기는 Thread에 한하여 강제로 Block시키고 삭제할 수 있으며 Blocked Thread의 수가 일정 비율을 넘기면 Container restart를 수행함으로써 불필요한 Thread 정리가 가능하며 야간 장애 발생 시 Down Time을 최소한으로 하여 스스로 재기동을 수행할 수 도 있습니다. 다만 356dayx 24hour 무중단 시스템에서는 강제 종료와 같은 설정은 지향해야 할 것입니다.

사이트 환경에 맞게 적절한 옵션을 파악하여 반영하면 보다 효율적인 운영이 가능할 것으로 판단됩니다.

고맙습니다.