tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David.Meldrum" <david.meld...@verizon.net>
Subject Re: Extra Threads in background
Date Fri, 01 May 2009 17:23:18 GMT
Chris, This is a good point.  What I am discovering is that while I was 
calling a terminate method on the Thread in the 
ContextListener.contextDestroyed() method, my thread lives for quite 
while, because it is sleeping and does not wake up to test the terminate 
flag for several minutes.  My solution was to reduce the sleep time down 
to a few seconds and only really do something every 20 time it wakes 
up.  This allowed it to discover the terminate flag much sooner.  I did 
not call the "destroy()" method because I though it was deprecated and 
dangerous.   I noticed that the Probe  application does have a destroy 
Thread  which works, but warns of being dangerous.

I am still trying to figure out why a second thread is spawned. Haven't 
gotten to bottom of that issue yet.
-d

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David,
>
> On 4/28/2009 10:52 PM, David.Meldrum wrote:
>   
>> I need a background task which I implemented as a thread that I stated
>> in the ContextListerner.
>>     
>
> [snip]
>
>   
>> The problem I noticed is that while I only call
>> the BackGroundThread.*start()* method once.  I see at least two threads
>> running in Tomcat (las seen in Thread dump and looking at it in
>> "Probe").
>>     
>
> Are you re-deploying your application at all? If you are only starting
> your thread, you will be starting a new thread for each deployment. So,
> if you re-start your application, a second (or third, or fourth) will be
> created.
>
> Tomcat doesn't kill your application's threads when the app dies. You
> need to end them yourself. Since you already have a ContextListener,
> just add a destroy() method that shuts down the background thread.
>
> Apologies if you're already doing this, but you didn't mention it and I
> figure it's the most likely scenario.
>
> - -chris
>   


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