tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gaurav Kushwaha" <>
Subject Re: how to make a scheduled event on tomcat
Date Sun, 04 Feb 2007 20:20:58 GMT
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.
Gaurav Singh Kushwaha

Ph: +91-9880110695
Bangalore, India.

On 2/2/07, Christopher Schultz <> wrote:
> 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
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla -
> rybxmprS5YtR2cmaA9Un8LU=
> =3oeA
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message