序.
로컬에서의 테스트에서는 극히 정상적으로 quartz스케쥴러가 작동하였고, 이를 테스트서버와 실서버로 옮겼을때는 동시에 두번씩 동작하는 문제가 발생했다.
세 서버의 Tomcat/Spring/Quartz의 버전은 완전히 동일...

1. 일단 큰 차이랄 수있는 OS/JVM의 차이를 의심하였다. 구글링을 해보니 비슷한 증상(윈도우 정상작동, 리눅스 스테이징으로 옮기니 발생)인 사람들을 여럿 발견... 희망이 보이기 시작....

벗뜨.. 이런 얘기한 사람들은 다 답을 얻지 못함...

2. 다음은 Spring 혹은 Quartz의 버그를 의심.
Spring + Quartz의 조합으로 비슷한 증상을 호소한 사람들이 미쿡(= 영어였다는 얘기다;;;)에는 꽤 많았다...
이는 web.xml에서 Spring의 ContextLoader가 중복호출되어 복수의 Quartz인스탄스가 생겨 발생하는 경우였다. 웹어플리케이션 상에서 둘 이상의 Listener or Servlet을 등록때 하나의 context정보 파일을 두 번 이상 부를 수 있는 경우가 있다는 것이다.

webapp의 lifecycle과 Spring의 Bean생성 과정을 자세하게 알지 못하면 쉽게 할 수 있는 실수였다... 드디어 찾았구나~ 하고 좋아했다...
 
근데...

이 경우라면 로컬에서는 이상없는 것이 설명되지 않았다...
로컬에서 이상이 없는 이유를 찾느라 한참을 소비해야했다...

결론적으로... 내 경우의 Spring설정은 완벽했다;;;

3. 처음부터 서버 설정을 크게 의심하지 않은 것은, 테스트 서버와 실서버가 모두 잘 돌고 있었기 때문이다. 또한 설정파일 역시 모두 공유해서 사용하고 있었기 때문에 시야를 벗어나는 좋은 이유가 되었다. 처음부터 톰캣 인스탄스가 2개인것은 의심해 보았다. 2개가 떠있어서 하나는 포트를 못열고 놀고만 있는... 그러나 스케줄러는 작동되고 있는... 하지만 이것에 해당하지는 않았다.

유일하게 공유되고 있지 않은 설정파일인 톰캣의 server.xml파일을 열어봤다...

....
<Host name="localhost" appBase="/tomcat/webapps"
    unpackWARs="true" autoDeploy="false"
    xmlValidation="false" xmlNamespaceAware="false">
    <Context path="" docBase="/tomcat/webapps/test" reloadable="false" />
</Host>
....

뭔가 감이 왔다;

그렇다, Host의 appBase는 여러 webapp들이 들어갈 母 디렉토리다. 즉, 이하의 디렉토리는 webapp의 자격조건을 가지고 있으면 자동으로 webapp로 구동되는 것이다.
Context는 이와는 별도로 webapp의 위치를 직접 지정가능하다.

결국 위의 설정은 두개의 'test' webapp를 구동하도록 만들었다. 스케쥴러도 두개가 뜬것이다.

Tomcat에서 동일한 Web Application Context 두 개가 뜬다한들 작동에는 별 문제가 없을 것이다. 둘의 ContextPath가 다르다면 말이다. 위의 경우 Host에서는 "test"라는 ContextPath로 webapp가 떴을 것이고, Context에서는 지정한대로 ""(=루트) ContextPath로 떴으니 아무런 문제가 없었던 건이다.

여튼 Tomcat설정시 Host의 appBase위에 Context로 설정할 app를 올리지 말아야한다. 이는 의도하지않은 작동을 야기한다. 본인은 다양한 이유로 appBase의 위치를 바꾸는 방법을 택했다.

結.
Quartz의 스케쥴러가 이중작동하는경우(굳이 이러한 경우가 아니더라도, 서버구동시 한번만 실행되도록 했는데 두번 실행되는 모든 경우).....

우선 Spring을 사용하는 경우는 Spring설정에 주의를 기울여라. Spring이 인스탄스의 라이프사이클을 제어하는 경우가 많아서, 개발자가 미처 인지하지 못하는 사이 인스탄스화가 일어날 수 있다. 구체적인 사례는 여기를 참조한다.

이게 아니라면 Container의 라이프사이클을 의심하라. 혹시 프로세스가 두개가 뜨지는 않았는지... 프로세스는 하나지만 복수의 Context를 구동하게 되지는 않았는지... 이 모든 것은 Container의 설정으로 해결해야 할 것이다. 1번의 경우(OS, JVM의심)도 결국 이러한 상황이었던 것으로 보인다.

이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn

휘발성으로 이용되는 파일들이나 로그파일등.. 파일이 생성된지 일정기간이 경과하면 파일을 삭제해야하는(하는게 좋은) 파일들이 있다. 이들을 삭제하기 위한 방법은....

* 생성된지 30일 이상 된 파일만 삭제

/usr/bin/find "대상디렉토리" -type f -ctime +30 -exec /bin/rm -rf {} \;

* 생성된지 30일 이상 된 비어있는 디렉토리만 삭제

/usr/bin/find "대상디렉토리" -empty -type d -ctime +30 -exec /bin/rmdir {} \;

리눅스 버전에 따라 -ctime이 먹지 않는 경우가 있다. 이때는 -mtime으로 대체(의미는 약간 다르지만)한다.

이러한 쉘을 crontab에 하루단위로 동작하도록 등록해두면 편리하겠죵?

이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn

무료 텔넷/SSH 클라이언트인 Putty는 많은 사람들이 사용하는 유명한 프로그램이지만, 한글 입력문제가 있어왔다. 때문에 KLDP에서 한글화 작업프로젝트가 있어왔고, 그 결과물로 한글PuTTY가 돌아다니고 있다.

하지만 오리지널 PuTTY가 버전업을 계속하고 있는 반면, 한글 PuTTY는 그 후 버전업이 없는 상태라 계속해서 이전버전을 쓸 수 밖에 없다(요거 상당히 찝찝하다...). 또한, 한글 PuTTY에서는 Serial통신 기능이 빠졌다고 한다.

이미 깔려있던 영문 PuTTY로 한글을 쓸 순 없을까 고민해서 검색해 봤더니 인터넷에서 좋은 방법이 이미 나와 있었다. 방법대로 해보니 이상없이 한글입력이 되었다!!

참고로 나의 PuTTY는 0.60버전이다.


원문 : http://cafe.daum.net/KingOfLinux/2LGH/34?docid=bCrN|2LGH|34|20070320164333&q=%C7%D1%B1%DB%20putty&srchid=CCBbCrN|2LGH|34|20070320164333

영문 오리지널 putty 한글 사용하기
SE 일을 하다 보니, 이것 저것 잡다한 일을 많이 하게 됩니다. ^^;
Unix/Linux 시스템(OS + Application)을 만지면 telnet 이나 ssh 를 많이 사용합니다.
그러다 보니, 한글 환경은 당연히 되야 작업이 편하지요.
하지만, KLDP에 있는 한글putty와 같은 한글 작업이 완료 된 것들은
Serial 통신 부분이 없습니다. 아마도 한글화 작업 과정에서 정상적으로 안되어 뺀것으로 알고 있습니다.
Putty 오리지널 설치 패키지 파일을 설치하고, 다음과 같은 작업을 하면, 터미널 접속시 한글 작업 및 콘솔(Serial 통신) 접속시 정상적으로 작업이 가능합니다.
네트워크(L4/L3/L2) 및 서버 장비에 Console 접속시 아무런 이상없이 접근이 가능했습니다.
SecureCRT와 같은 상용프로그램을 자주 사용하시는 분이라면 가볍고, GNU GPL 라이센스 정책을 따르는 오픈소스를 사용해 보시 것도 좋은 생각이라 사료됩니다. ^^

1. putty 0.59 (최신버전) 다운(http://www.chiark.greenend.org.uk/~sgtatham/putty/)
2. putty session을 하나(Default Settings) 만들어서 save 한다.
3. 윈도우 regedit를 실행한다.
4. HKEY_CURRENT_USER - Software - SimonTatham - PuTTY - Sessions - Default%20Settings 항목을 선택한다.
5. 오른쪽 창에 FontCharSet이 0으로 되어 있는데, 그걸 16진수 81(10진수 129)로 바꾼다.
6. Putty로 Serial(콘솔) 및 Telnet, SSH 접속해 보세요. 잘 될 겁니다.



Sessions 밑에는 기존에 만들었던 모든 세션들이 있다. 이들의 FontCharSet값을 변경해주면 기존 세션에도 모두 적용된다.

p.s. 원문이라고 표현한 다음까페의 글이 실제 작성자의 오리지날 원문같지는 않다. 왜냐하면 해당글이 [펌]게시판에 있고, 첫줄처럼 제목이 내용속에 함께 들어있었기 때문이다.

이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn
'Best Practices for Speeding Up Your Web Site' 라는 타이틀로 Yahoo에서 공개한 Tip들이다.

http://developer.yahoo.com/performance/rules.html


비교적 손쉬운 노력으로 이룰 수 있는 소소한 퍼포먼스 향상 기술들이다.
이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn
Apache나 Tomcat을 비롯한 많은 서버 어플리케이션들이 로그를 생성하며, 그들은 날짜기반의 로그파일 명을 갖는 경우가 많다. 로그파일은 순수 텍스트기반의 파일로서 압축률이 매우 좋기 때문에, 지난 로그파일들은 압축해서 보관하는 것이 효과적이다.

일 단위 로그는 금일 24시가 지난뒤에야 최종 완성된 로그파일이 생기기 때문에 익일에 파일을 압축하여야 한다. 때문에 crontab에 다음과 같이 등록해준다.
1 0 * * * /opt/script/compress_log.sh

compress_log.sh은 아래와 같이 편집하고 반드시 실행권한을 준다.
gzip /usr/local/apache2/logs/access.log.`date +%Y%m%d --date="1 days ago"`

결국 일자가 포함된 파일명을 추출하는 `date +%Y%m%d --date="1 days ago"`부분이 핵심이다.

crontab의 구체적 사용법은 여기를 참조한다.
이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn

ASFDBCP를 사용하나, 커넥션이 자주 사용되지 않는 Java Application의 경우에 Database에 의해서 커넥션이 단절되는 현상이 나타날 수 있다.
MySQL의 경우에는 8시간동안 사용되지 않은 커넥션(DBCP가 물고있던..)은 MySQL이 강제로 끊어버리게 되는데, 이렇게 되면 Java Application이 기대대로 동작하지않게 된다. 보통은 아래와 같은 메시지가 나타나게 된다.

'com.mysql.jdbc.CommunicationsException: Communications link failure
Last packet sent to the server was 18 ms ago.'

이러한 경우 MySQL의 JDBC설정 시

url="jdbc:mysql://127.0.0.1:3306/test?autoReconnect=true"

와 같이 'autoReconnect'옵션을 주게 되면, 커넥션에 문제가 있을 경우 다시 접속하게 된다.
그러나, 이 경우에도 끊어진 후 처음 한번의 시도는 실패가 나게 된다(이때 문제가 있다는것을 알게 되는 것이므로..).
 
이때는 추가적인 DBCP옵션인 'validationQuery'값의 설정으로 해결 가능하다.

validationQuery="select 1" => MySQL의 경우
validationQuery="select 1 from dual" => Oracle의 경우

validationQuery는 가장 간단한 결과값을 갖는 쿼리를 넣어야 한다. 왜냐하면 모든 사용자쿼리의 실행전에 이 쿼리가 실행되어 validation을 체크하기 때문이다.
valicationQuery가 추가적인 부하이기 때문에 실제로 커넥션 사용이 거의 없는 Application에서만 사용할 것을 권장한다.

validationQuery에 대한 추가적인 설정은 여기를 참조한다.

이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn

crontab -e로 편집모드로 진입. 편집이 완료되면 :wq 로 종료
별도의 재기동절차는 필요없다.

Quick Reference는 아래를 참조
http://www.adminschoice.com/docs/crontab.htm

원문 : http://hbesthee.tistory.com/276

cron 데몬이 지정된 시간에 주기적인 처리를 위한 정보를 저장해 두는 테이블 파일입니다.

각 줄은 "다섯개의 시간과 날짜 필드, 다음에, 사용자 이름(시스템 crontab 파일일 경우), 다음에 실행될 명령" 이런 형식이다. 지정한 명령은 데몬에 의해, 지정한 날짜, 시간에 실행된다.

필드           사용할 수 있는 값
-----         -----------------
            0-59
            0-23
날짜          0-31
            0-12 (아래 참조, 달 이름을 사용 가능)
요일          0-7 (0 또는 7: 일요일 , 요일이름을 사용 가능)

한 필드에 `*' 문자가 올 수 있는데, 이것은 그 단위 전체를 말한다. (예를 들어, 날짜 부분에 `*' 문자가 오면 `매일'을 뜻한다)
숫자의 범위가 사용될 수 있다. 범위는 하이픈(`-') 문자로 지정하며, 앞에 숫자가 뒷 숫자보다 작아야한다. 예를 들어, 시간 필드에 8-11 이 오면, 8, 9, 10, 11시를 뜻한다.
또한 이 값들은 나열될 수 있으며, 그 구분은 쉼표(`,')로 한다. 예: 1,2,5,9, 0-4,8-12.
값의 범위를 지정할 때, 특정 단위로 건너 뛸 수 있는데, 이것은 그 범위 다음에 `/<숫자>' 형식으로 덧붙혀 준다. 예를 들어, 시간 필드에 `0-23/2' 값이 사용되면, 이것은 두시간 마다, 즉 `0,2,4,6,8,10,12,14,16,18,20,22' 시를 뜻한다. 또한 `매 두시간 마다'라는 뜻으로, `*/2' 이런식으로 사용될 수 있다.
여섯번째 필드(줄의 마지막)에는 실행시킬 명령이 온다. 그 명령이 실행될 때 줄을 나누는 것은 `%' 문자로 하며, 즉, 이것은 쉘에 의해서 다른 명령이 실행됨을 의미한다. (`%' 문자 앞에 있는 것이 하나의 쉘 명령이며, 뒤에 있는 것이 또다른 하나의 쉘 명령임을 뜻한다.) 또한 한 명령인데, 부득이하게 줄을 나누워야 할 경우에는 백슬래쉬(\) 문자를 사용한다.

다른 유저의 profile을 이용해야 하는 경우에는 다음과 같이 처리한다.
/bin/su - myuser -c "myprog">/dev/null 2>&1


@ 주의점
줄, 공문자나, 탭문자로 시작하는 줄, 줄 첫칸에 `#' 문자가 있는 줄은 모두 무시된다.
명령이 지정되어 있는 줄 안에서는 주석을 사용할 수 없다.
환경변수 설정하는 곳에는 이 주석문을 사용할 수 없다.

@ 사용예제
# 명령어를 실행 쉘 지정
SHELL=/bin/sh
# 편지를 받을 사용자 지정
MAILTO=paul
#
# 매일 00시 05분에 특정작업을 하는 경우
5 0 * * *       $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# 매달 1일 오후 2시 15분에
15 14 1 * *     $HOME/bin/monthly
# 월요일부터 금요일 까지 매일 오후 10시에.
0 22 * * 1-5   mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "이것은 매일 0, 2, 4, ... 시 23분에 보여집니다."
5 4 * * sun     echo "이것은 매 일요일 오전 4시 5분에 보여집니다."

이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by A.J.Kuhn

BLOG main image
A.J.Kuhn, Endless supply of passion!
Generalist A.J.Kuhn의 general한 이야기 by A.J.Kuhn

카테고리

분류 전체보기 (89)
Human (3)
Employee (6)
Developer (11)
Musician (0)
Snowboarder (10)
Baseball Player (0)
Traveler (0)
Reviewer (59)

글 보관함

달력

«   2010/03   »
  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      
Total : 78,684
Today : 6 Yesterday : 24