Spring SchedulerFactoryBean 질문입니다.
이재일
http://static.springsource.org/spring/docs/2.5.x/reference/scheduling.html
문서를 통해 잘 했구요.
이제 서버에 적용을 하면 되는데요. 적용할서버가 2대입니다. 그러니 두대중 1대만 스케쥴러가 실행이 되면 되는데, 기존에는
properties파일 하나두고 true, false값을 저장하고, 설정이 된 서버만 쿼츠를 직접구현한 클래스에서 if else
로 구분해서 쿼츠를 등록하게 처리를 했는데요.
applicationContext.xml에 쿼츠 설정을 모두 두고, 두대의 서버중 한대만 적용을 하려면 어떤 방법이 좋을까요?
지금은 그냥 SchedulerFactoryBean을 상속해서 클래스를 만들어 이걸 applicationContext.xml에 등
록해버릴까 고민중입니다. 이런 경우는 흔할것 같은데요. 어떻게들 하시나요??
이재일
SchedulerFactoryBean 안에 autoStartUp이라는 boolean이 있네요. applicationContext에
<property name="triggers">
<list>
....
</list>
</property>
<property name="autoStartup" value="${job.start}"/>
</bean>
Sewon Ann
문제를 좀 돌려서, 이전에도 비슷한 글타레가 있었던 것 같은데 WAS 위에 quartz 를 얹어 돌리는 게 좋은 방법일까요?
밑의 재일님 경우, 명시적으로 말씀하시진 않았지만 아마 WAS 안에 한쪽의 quartz 가 돌면서 배치를 돌리는 것 같습니다. 동일한 프로그램을 두 군데 배포를 하구요.
이 경우 WAS 는 web 처리만 하도록 하고 별도의 배치 daemon 을 돌리는 것이 좋을지, 아니면 재일님 경우와 같이 scheduler 도 포함해서 배포를 하되 선택적으로 돌리는 것이 좋을 지 궁금하네요.
on-demand-batch 등이 필요하면 was 쪽에 올려서 바로 재사용할 수 있으니 그건 좋을 것 같기도 한데, (앗, 이 경우도 quartz 가 한쪽에서만 도니 맞는 말은 아닌 듯 합니다.) 아무래도 batch 는 daemon 으로 따로 놀리는 게 심적으로 맞을 것 같기도 하구요. 웹 어플리케이션은 UI 등등 해서 재배포 할 일이 많을 텐데, 불필요하게 daemon 까지 영향을 받는 것을 줄일 수도 있을 듯 하고요.
다른 분들은 어떻게 생각하시나요?
이재일
지금 관리하는 프로젝트는 quartz로 된부분도 있고, tomcat위에 있지 않는 java로 된 프로세스도 있습니다. 관리하기 귀찮아서 quartz로 옴길까 고민중인데, 좀 심도 있는 고민을 해볼필요가 있겠네요.
Sanghyuk Jung
별도의 daemon에서 단순 스케쥴에 따른 실행만을 한다면 crontab에 등록을 하는 것도 고려해볼만합니다.
전에 정리해둔 내용이 있는데, 공유해드립니다.
많은 분들이 Quartz와 Crontab 사이에서 고민을 하고 계신 것으로 알고 있고, 그런 질문을 많이 받아왔습니다. 아래와 같이 여러 방식의 장단점을 정리해봤습니다.
l Crontab에서 쉘스크립트를 통해서 job을 실행하는 클래스를 호출하는 방식
n 장점
u 소스 수정 배포 후 서버 재시작 등의 작업이 필요 없다.
u 권한이 있는 사람만 서버에 들어가서 쉘을 실행할 수 있으니 보안 문제가 적다.
n 단점
u 웹Application 과는 다른 패키징(jar파일로 패키징)을 하고 실행할 shell 스크립트를 만들어야 한다. (http://www.ksug.org/96 참조)
u 매번 job은 다른 JVM에서 실행되므로
l 자주 실행되는 Job이라면 로딩시간만큼의 실행시간의 손해가 있음
l Job 간의 메모리를 통한 정보공유는 할 수 없다.
l Web container안에서 Quartz를 통해 Job을 호출하는 방식
n 장점
u Job실행 때 로딩시간을 단축할 수 있다.
u 스케줄 정보를 Application 내부에 저장해 둠으로써 소스만 보고 확인해 볼 수 있고, SVN을 통한 이력관리 등의 장점이 있다.
u 웹을 통해 수동으로 Job을 실행할 때 같은 JVM안에 있으므로 간단한 클래스 호출만으로 가능하다.
n 단점
u 배포 후 서버 재시작 등 필요
u 배치 모듈이 아닌 다른 Web 모듈과 함께 올라간다면 배포나 실행 시에 상호영향을 받는다.
u 배치 Job내에서 static 영역에 가지고 있으면서 자원해제를 하지 않는 객체가 있다면 메모리 full 가능성 위험
l MapJobRepository의 사용시 주의 (명시적으로 clear를 하지 않으면 메모리가 언젠가 넘침)
l 배치 모듈을 웹컨테이너올려 넣고, 그 모듈을 URL로 호출하는 쉘스크립트를 만들어서 Crontab에 올리는 방식
n 주로 Quartz방식의 장,단점과 유사.
n 호출하는 URL이 외부에 열려있지 않은지 주의해야 함
해당 Application의 Job의 성격을 보고 몇 분 주기 등 자주 실행되는 Job이 다수라면 Quartz를, 실행 주기와 실행시간이 긴 Job이 많을수록 별도의 JVM으로 띄울 수 있는 Crontab + 클래스 별도 실행이 유리하게 느껴집니다. 이 두 가지 유형이 모두 섞인 어플리케이션인 경우에는 메모리 등 자원관리와 배포에 특별히 유의하면서 Quartz를 써야 하지 않나 생각됩니다.
어느 정도 배치처리를 많이 하시는 팀에서는 배치만을 위해서 별도의 Tomcat을 띄우셔서 다른 웹모듈과의 영향 관계는 없이 관리하시는 것으로 알고 있습니다. 다만 그렇게 하더라도 하나의 서버에 여러 개의 업무영역의 배치가 올라가면 그 모든 Job들의 실행주기와 처리시간을 다 고려해서 배포시간을 결정해야 됩니다. 규모가 커질수록 한 사람이 모든 배치처리의 정보를 머리 속에 다 담고 있기가 힘드니 관리가 힘들어질 수 있습니다.
Myoungsoo Shin
위의 분 께서 말씀하신 것 처럼 초기 부트스트래핑할때 자바가 쓰는 비용이 크고
하이버네이트 같은 경우도 작지 않은 듯합니다.
하지만 5분마다 도는 잡이 아니고 하루에 새벽에 한번 정도라면 나머지 시간에 떠있는것도
리소스를 좀 낭비한다고 볼수도 있겠네요..(뭐 그정도야. 쿨럭;;)
cronjob을 관리하나 tomcat하나 관리하나 오십보 백보일 듯 합니다. :-)
전 cronjob으로 몇개 안되는 8개정도? 걸어두고 쓰는데. 흠. 종종 프로세스가 떠있는게 있는지 봅니다. (응?;;) ㅎㅎ (농담입니다.;)
cronjob이 작성하기 편하긴 합니다만..
간단한 job이면 python이나 ruby로 작성해서 cronjob쓰시죠! ㅎㅎ
2009/11/2 Sanghyuk Jung <ben...@gmail.com>:
--
email: anar...@gmail.com
blog: http://anarcher.appspot.com/
Myoungsoo Shin
현재 was의 application context에 스케줄러를 추가하는 게 가장 무난하게 하신듯 하네요. :-)
2009/11/3 Myoungsoo Shin <anar...@gmail.com>: