마법수정화살

tomcat 을 사용하고 jsp 소스코드를 수정하여 반영 하는 상황이라고 가정.

오래된 시스템 tomcat 5 이하? 라고 가정

2011년 8월 달에 작업된 파일을 2014년 10월에 수정하는 것으로 가정. 

작업을 진행 하려 했으나 실패하여 롤백을 해야하는 상황이라고 가정

운영서버에 바로 반영 하는 것으로 가정

이런 가정이 맞아 떨어지면 무서운 경험을 할 수 있다. 

꼼꼼한 사람들은 작업전에 기존파일을 이쁘게 백업 해 놓는다

test.jsp : 수정일자 2011년 08월 10일

test.jsp : 수정일자 2014년 10월 8일

반영을 하고 테스트를 하는데.. 뭔가 잘안되서 롤백을 하는 상황.

예전 파일을 다시 운영서버에 덮었는데 정상 동작 하지 않는다. 

여기서 집중력을 잃으면 홀로 헤메이다 큰 낭패를 보며 식은땀을 등으로 흘릴 수 있다.

집중력을 있다면  디버깅을 시작한다.

센스가 있다면 원인을 추측하여 소스보기를 통해 빨리 원인을 찾는다.

경험이 있다면 롤백파일을 수정해서 수정일을 최신화 하거나 tomcat의 work 디렉토리에 해당 파일을 확인하고 지운다.

배신자 톰캣은 때로는 아래와 같은 행동을 하는데 버전별로 어떤지는 모른다.

이전날짜 jsp 파일은 컴파일을 안한다.

톰캣 재시작을 아무리 해도. 컴파일을 안한다. 

thread 덤프를 획득 했다면 분석을 해보자.

툴을 이용하자. 

SUM JDK :  TDA , visualvm 플러그인으로도 사용 가능 하다.

IBM JDK : TMDA 

jar 하나이고 java -Xmx500m -jar jca455.jar > 이런식으로 실행할 수 있다. 

TMDA :http://pic.dhe.ibm.com/infocenter/isa/v4r1m0/index.jsp?topic=%2Fcom.ibm.esupport.tool.tmda.doc%2Fdocs%2Freadme.htm

thread 덤프를 확인해 보자

전체적인 문제라면 

전체에서 사용하는 객체에서 lock이 있거나 threadpool을 차서 더이상 요청을 처리할 수 없을때. 

특정 동작이 문제라면 

해당 Thread를 찾아 stack trace로 확인한다.

1. 전체 thread 숫자 와 상태 확인 (IBM JDK의 경우 더많은 시스템 정보를 제공한다.)

- 전체 thread가 was에서 허용 가능한 자원을 다 썼다면 해당 웹 어플리케이션은 응답이 없을 것이다.

2. 각 thread의 상태 확인.

데드락이 없는지 BLOCKED나 WAIT를 유심히 확인한다.

thread는 각각 고유한 정보인 THreadID를 가지고 있다. 문제가 있는 Thread 우선 확인해야 한다. 

Thread 덤프는 한 시점에 대한 정보이므로 여러번 수집하여 어떻게 동작하는지 확인해야 하는 경우도 있다.

3. thread의 stack trace를 유심히 보자.  (아래와 같은 상황을 찾을 수 있다.)

- 어떤 메서드를 실행 중인지

- 어떤 메서드에서 대기중인지 (해당 메서드에 동기화 처리가 되어있는지 확인해 본다)

- DB 풀을 기다리는지 

- DB의 응답을 기다리는지 

등등