tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] how to make a scheduled event on tomcat
Date Fri, 02 Feb 2007 14:17:10 GMT
-----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


Mime
View raw message