tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: How to run servlet for every 30 minutes in Tomcat 4.1.30
Date Tue, 28 Dec 2004 16:49:13 GMT

Dennis Payne wrote:
> Frank,
> I'm using threads and didn't know I was vulnerable.  

I'm not sure "vulnerable" is really the right word, but I'll go with it :)

> Here's how I've 
> done it.  I created a class that implements runnable and call its 
> initialize method from a servlet init method at application startup. 
>  The initialize method creates a thread and sets a low priority for it.

Roughly what I do too, except that my class extends Thread and I kick it 
off from a Struts plug-in.  Same effect though.

>  The run method sleeps the thread and wakes it every two minutes.
> A processing class contains the methods that queries the database 
> (postgres).

Same here.  I think I wake my threads every minute though.

> 1. Is this what you call a daemon thread?

Nope.  If you take a peak at the javadocs for the Thread class, you'll 
see a method setDaemon(boolean).  This marks a thread as a daemon 
thread.  The difference, if I remember correctly, is that the JVM won't 
shut down until all remaining threads are daemon threads.  Threfore, if 
you spawn a "normal" thread, you can hold up the JVM from shutting down 

This is in fact the situation I had... My Tomcat instance could never be 
properly shut down because the threads I had spawned where not daemon 
threads.  Marking them as such solved that problem.

To the best of my knowledge, being a daemon thread doesn't implicitly 
say anything about a threads priority.  I think you could have a daemon 
thread set at high priority if you wanted.  I suspect most daemon 
threads are bumped to a lower priority though, as I do.

> 2. Is this better done using cron?  if so how do I ensure that it runs
> with a lower priority than my application code?
> Phil

This is a matter of opinion, and there are some reasonable arguments for 
both points of view.

My personal opinion is that if you have some periodic process that is 
going to need portions of your system, whether it's resources available 
in the container or shared code, as you do, then a low-priority daemon 
thread spawned at application startup is a good approach, assuming you 
write it carefully and solidly.

For instance, in my case, my daemon threads do some record aging in the 
database, so to me it makes sense to share the same connection pool as 
the application itself.  I also use a number of classes and functions 
that are part of the webapp itself, and I don't like the idea of 
duplicating the code for a cron job to use (sure, could just be a matter 
of setting up a classpath to those classes, but it's an extra 
dependency, and that doesn't thrill me).

But, if these tasks were volatile in any way, or they had to run 
independently of the app itself no matter what, the cron job approach 
would probably be preferable.

As for ensuring it runs at a lower priority than your application code, 
when running via cron, that's an answer I can't give you.  I'm frankly a 
Unix newbie, more or less, so someone else out there would be better 
suited to answer that.  I think you'd have to have it run at a lower 
priority than your app server, and I'm sure there's switches to set 
priority of jobs, but I don't know them.

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message