You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2007/02/02 15:17:10 UTC
Re: [OT] how to make a scheduled event on tomcat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jacob,
Jacob Rhoden wrote:
> Christopher Schultz wrote:
>> You're better off not using Tomcat for this kind of thing. That's what
>> cron and other system software packages are for.
>>
> I am curious, I find that moving the cron activities into the war file,
> simplifies greatly the task of deployment and maintenance, why would you
> not do it this way?
Here are several reasons not to implement batch scheduling into your web
application:
1. It is generally not part of the application, but part of the
"system" that you are building. I like to keep components as
simple and discrete as they can possibly be, instead of building
one monster component.
2. While "every two weeks" was not clearly defined by the OP, I take
it to mean actually every 14 days or so without interruption. In
order to do that with a webapp, you'll need a lot of code to manage
the schedule: the last time the event was triggered, how long before
the next event, what happens if the server is down when the event
should occur, etc. Otherwise, webapp reloads (which ought to be
rare in production, but still...) will interfere with scheduling.
3. The webapp is limited to the permissions associated with the JVM.
Unless you use Runtime.exec (which is arguably a mistake from a
webapp), you are stuck running as "tomcat" or whatever user
you run.
4. Following #3, you may have to alter your security manager's
privileges if you want to do anything interesting. Perhaps
this is not a big deal, but if you have to open-up your security
manager, you might be compromising security in other parts of your
application.
5. Your batch job runs at the same priority as the webapp. Yes, you can
set the thread priority, but you can't "nice" the process or anything
like that.
6. If there's a problem with your batch job, it could bring down your
entire application. (Then again, that's what testing is for).
Seriously, though. If your batch job starts to use more memory than
you thought it would, your webapp users could start to feel the
effects through sluggish server responses, etc.
Here are several reasons to use cron instead:
1. Cron is already written, so you don't have to write a bunch of code
to manage your schedule just to get batch processing to run.
2. The counter-arguments to everything above: you can "nice" a process,
run it under any uid you want, it runs in its own separate memory
space, etc.
3. When configured to do so, cron automatically emails you a report
for your cron job, so you know what's up.
The bottom line for me is that scheduled jobs like this are (usually)
simply not part of the webapp, so they don't belong in there. No
reasonable production web application is just a fire-and-forget WAR file
deployment. A deployment process containing an upgrade to your cron job
(which is probably unlikely to change across release anyway) should not
be unmanageable for someone whose job it is to do deployments.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFw0fm9CaO5/Lv0PARAjXwAJ0TYsoP4SfAdgEfP4J7AAPMDYW2nACgtKxf
rybxmprS5YtR2cmaA9Un8LU=
=3oeA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to make a scheduled event on tomcat
Posted by Gaurav Kushwaha <ga...@gmail.com>.
Thanks Chirstopher for a detailed reply. A very insightful and convincing
mail indeed. My problem is I have never tried writing a cron job before. So
I have no idea on how to go about it. Hence I will try quartz first. Going
by its description here, it should serve my purpose for the time being.
Still a big thanks to everyone for pitching in.
Regards,
Gaurav Singh Kushwaha
http://www.chakpak.com
Ph: +91-9880110695
Bangalore, India.
On 2/2/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jacob,
>
> Jacob Rhoden wrote:
> > Christopher Schultz wrote:
> >> You're better off not using Tomcat for this kind of thing. That's what
> >> cron and other system software packages are for.
> >>
> > I am curious, I find that moving the cron activities into the war file,
> > simplifies greatly the task of deployment and maintenance, why would you
> > not do it this way?
>
> Here are several reasons not to implement batch scheduling into your web
> application:
>
> 1. It is generally not part of the application, but part of the
> "system" that you are building. I like to keep components as
> simple and discrete as they can possibly be, instead of building
> one monster component.
>
> 2. While "every two weeks" was not clearly defined by the OP, I take
> it to mean actually every 14 days or so without interruption. In
> order to do that with a webapp, you'll need a lot of code to manage
> the schedule: the last time the event was triggered, how long before
> the next event, what happens if the server is down when the event
> should occur, etc. Otherwise, webapp reloads (which ought to be
> rare in production, but still...) will interfere with scheduling.
>
> 3. The webapp is limited to the permissions associated with the JVM.
> Unless you use Runtime.exec (which is arguably a mistake from a
> webapp), you are stuck running as "tomcat" or whatever user
> you run.
>
> 4. Following #3, you may have to alter your security manager's
> privileges if you want to do anything interesting. Perhaps
> this is not a big deal, but if you have to open-up your security
> manager, you might be compromising security in other parts of your
> application.
>
> 5. Your batch job runs at the same priority as the webapp. Yes, you can
> set the thread priority, but you can't "nice" the process or anything
> like that.
>
> 6. If there's a problem with your batch job, it could bring down your
> entire application. (Then again, that's what testing is for).
> Seriously, though. If your batch job starts to use more memory than
> you thought it would, your webapp users could start to feel the
> effects through sluggish server responses, etc.
>
> Here are several reasons to use cron instead:
>
> 1. Cron is already written, so you don't have to write a bunch of code
> to manage your schedule just to get batch processing to run.
>
> 2. The counter-arguments to everything above: you can "nice" a process,
> run it under any uid you want, it runs in its own separate memory
> space, etc.
>
> 3. When configured to do so, cron automatically emails you a report
> for your cron job, so you know what's up.
>
> The bottom line for me is that scheduled jobs like this are (usually)
> simply not part of the webapp, so they don't belong in there. No
> reasonable production web application is just a fire-and-forget WAR file
> deployment. A deployment process containing an upgrade to your cron job
> (which is probably unlikely to change across release anyway) should not
> be unmanageable for someone whose job it is to do deployments.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFw0fm9CaO5/Lv0PARAjXwAJ0TYsoP4SfAdgEfP4J7AAPMDYW2nACgtKxf
> rybxmprS5YtR2cmaA9Un8LU=
> =3oeA
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] how to make a scheduled event on tomcat
Posted by Gaurav Kushwaha <ga...@gmail.com>.
Thanks Chirstopher for a detailed reply. A very insightful and convincing
mail indeed. My problem is I have never tried writing a cron job before. So
I have no idea on how to go about it. Hence I will try quartz first. Going
by its description here, it should serve my purpose for the time being.
Still a big thanks to everyone for pitching in.
Regards,
Gaurav Singh Kushwaha
http://www.chakpak.com
Ph: +91-9880110695
Bangalore, India.
On 2/2/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jacob,
>
> Jacob Rhoden wrote:
> > Christopher Schultz wrote:
> >> You're better off not using Tomcat for this kind of thing. That's what
> >> cron and other system software packages are for.
> >>
> > I am curious, I find that moving the cron activities into the war file,
> > simplifies greatly the task of deployment and maintenance, why would you
> > not do it this way?
>
> Here are several reasons not to implement batch scheduling into your web
> application:
>
> 1. It is generally not part of the application, but part of the
> "system" that you are building. I like to keep components as
> simple and discrete as they can possibly be, instead of building
> one monster component.
>
> 2. While "every two weeks" was not clearly defined by the OP, I take
> it to mean actually every 14 days or so without interruption. In
> order to do that with a webapp, you'll need a lot of code to manage
> the schedule: the last time the event was triggered, how long before
> the next event, what happens if the server is down when the event
> should occur, etc. Otherwise, webapp reloads (which ought to be
> rare in production, but still...) will interfere with scheduling.
>
> 3. The webapp is limited to the permissions associated with the JVM.
> Unless you use Runtime.exec (which is arguably a mistake from a
> webapp), you are stuck running as "tomcat" or whatever user
> you run.
>
> 4. Following #3, you may have to alter your security manager's
> privileges if you want to do anything interesting. Perhaps
> this is not a big deal, but if you have to open-up your security
> manager, you might be compromising security in other parts of your
> application.
>
> 5. Your batch job runs at the same priority as the webapp. Yes, you can
> set the thread priority, but you can't "nice" the process or anything
> like that.
>
> 6. If there's a problem with your batch job, it could bring down your
> entire application. (Then again, that's what testing is for).
> Seriously, though. If your batch job starts to use more memory than
> you thought it would, your webapp users could start to feel the
> effects through sluggish server responses, etc.
>
> Here are several reasons to use cron instead:
>
> 1. Cron is already written, so you don't have to write a bunch of code
> to manage your schedule just to get batch processing to run.
>
> 2. The counter-arguments to everything above: you can "nice" a process,
> run it under any uid you want, it runs in its own separate memory
> space, etc.
>
> 3. When configured to do so, cron automatically emails you a report
> for your cron job, so you know what's up.
>
> The bottom line for me is that scheduled jobs like this are (usually)
> simply not part of the webapp, so they don't belong in there. No
> reasonable production web application is just a fire-and-forget WAR file
> deployment. A deployment process containing an upgrade to your cron job
> (which is probably unlikely to change across release anyway) should not
> be unmanageable for someone whose job it is to do deployments.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFw0fm9CaO5/Lv0PARAjXwAJ0TYsoP4SfAdgEfP4J7AAPMDYW2nACgtKxf
> rybxmprS5YtR2cmaA9Un8LU=
> =3oeA
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>