tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From phil campaigne <pcampai...@charter.net>
Subject Re: How to run servlet for every 30 minutes in Tomcat 4.1.30
Date Tue, 28 Dec 2004 19:29:45 GMT
Frank W. Zammetti wrote:

>
> 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 properly.
>
> 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,
I also am doing record aging.  I want to move records older than two 
minutes to a centralized server for processing.  Think of it as multiple 
data collection servers and a centralized data processing server.  I'm 
thinking that the daemon to schedule queries against the data collection 
servers should execute on the centralized server.  

I'm wonder if this form of light weight replication is a good practice. 
Does anyone have some insite on this?
Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message