Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <s1d123b7.094@mail.mtctrains.com>
Date: Tue, 28 Dec 2004 09:12:58 -0700
From: "Dennis Payne" <DENNIS@mtctrains.com>
To: <tomcat-user@jakarta.apache.org>
Subject: Re: How to run servlet for every 30 minutes in Tomcat 4.1.30
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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