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 16:33:50 GMT
Dennis Payne wrote:

>If you are running Linux or Unix check the syntax for the 'nice'
>command.
>
>  
>
>>>>pcampaigne@charter.net 12-27-2004 18:55 >>>
>>>>        
>>>>
>Frank W. Zammetti wrote:
>
>  
>
>>It's interesting, Craig and I had an exchange about threads in
>>    
>>
>servlet 
>  
>
>>containers last week... I can't find a link to the thread
>>    
>>
>unfortunately.
>  
>
>>Anyway, the basic idea behind that "don't spawn your own threads 
>>inside a servlet container" admonishment is based more on the fact 
>>that it's quite easy to screw up doing so, more than it has to do
>>    
>>
>with 
>  
>
>>virtually anything else.
>>
>>You want the servlet container to manager resources for you, and you
>>    
>>
>
>  
>
>>lose that by spawning your own threads.  The container isn't aware of
>>    
>>
>
>  
>
>>the threads, so it can't control them for things like graceful 
>>shutdowns or simply trying to control resource utilization.  Many 
>>people, including me, tend to ignore that warning when the situation
>>    
>>
>
>  
>
>>warrants it, but you have to be extra-careful.
>>
>>For instance, you don't under any circumstances want to hold on to 
>>references to response, request or session objects because you don't
>>    
>>
>
>  
>
>>manage them.  You also, unless you really have a need and know what 
>>your doing, want to spawn threads to handle requests at all.  Any 
>>threads you do spawn in a container should tend to be independent 
>>units of execution.  If your use case fits that description, you can
>>    
>>
>
>  
>
>>get away with it relatively safely.
>>
>>That being said, spawning things like daemon threads for low-level 
>>behind-the-scenes type processing is generally OK, so long as you are
>>    
>>
>
>  
>
>>careful (i.e., be sure no runaway processing can occur, make sure it
>>    
>>
>
>  
>
>>will shut down gracefully, etc).  You might be able to use something
>>    
>>
>
>  
>
>>like that in this case, you'll have to decide.  If your using Struts,
>>    
>>
>
>  
>
>>you can spawn the thread from a plug-in, as I've done in the past,
>>    
>>
>but 
>  
>
>>there are non-Struts equivalents (worse comes to worse, just do it in
>>    
>>
>
>  
>
>>a servlet.init()).  Do yourself a favor and make the thread
>>    
>>
>processing 
>  
>
>>functional independent of your app essentially, and even make it so 
>>it's not aware it's running in a servlet container.  But again, 
>>caution is the key.  If you make it a demon thread and set it's 
>>priority as low as you can and be sure to not hold on to a reference
>>    
>>
>
>  
>
>>to it, I've found that works just fine under a number of app servers
>>    
>>
>
>  
>
>>on a numeber of OSs.
>>
>>The bottom-line is that really that psuedo-rule is around because 
>>people tend to shoot themselves in the foot when using threads a bit
>>    
>>
>
>  
>
>>too often, so better to advise against getting into a situation where
>>    
>>
>
>  
>
>>you might do that.  But, if your confident in your ability, and 
>>believe the use case really warrants it, you CAN do it, and
>>    
>>
>relatively 
>  
>
>>safely.
>>
>>    
>>
>Frank,
>I'm using threads and didn't know I was vulnerable.  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.
>
> The run method sleeps the thread and wakes it every two minutes.
>A processing class contains the methods that queries the database 
>(postgres).
>  
>1. Is this what you call a daemon thread?
>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
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org 
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>  
>
Will do, thanks Dennis.
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