You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Delbecq <de...@oma.be> on 2007/06/06 16:55:14 UTC
webappclassloader won't get garbage colelcte, need suggestions (out
of memory)
Hello,
Trying to locate memory leak issues (not garbage collected classes &
classloader) i noticed this huge problem:
My webapp uses libraries that spawn helper Threads, using the default
ThreadGroup. Those Helper Thread are subclasses of java.lang.Thread that
override the run(). After stopping properly all those Threads at webapp
shutdown (they have all existed from run() ), it seems those Threads are
still referenced by the main ThreadGroup. Shouldn't tomcat clean the
ThreadGroup when a webapp is undeployed? This indirect directional link
between a system ThreadGroup and WebappClassLoader loader classes
prevents garbage collecting.
Am currently working on a context listener in my webapp that will clean
it at destroy time, but am pretty sure this should be the container's job.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: webappclassloader won't get garbage colelcte, need suggestions
(out of memory)
Posted by David Delbecq <de...@oma.be>.
Hi, thanks for suggestions.
All threads are terminated properly. I got confused in profiler because
another webapplicaiton, still running, created similary named Thread. So
i thought terminated Thread were still attached to ThreadGroup, maybe
it's not the case. Am still trying to figure why some Object Instance
still get marked as 'alive' in my profiler and prevent classloader
garbage collecting.
Sorry for mis analysing of problem.
En l'instant précis du 07/06/07 13:18, Johnny Kewl s'exprimait en ces
termes:
> No, imagine if you used a thread to say send an email.
> The webapp is done, tomcat is idling and it whacks your thread that
> hasnt done the email yet.
>
> You see it in normal java apps as well, ie if a thread is still busy
> and you close the app, if you look at the processes, the thread is
> keeping it alive.
>
> You have to signal your thread, so perhaps when the class that started
> the threads is destroyed, it sets a variable that the threads can see,
> and they start shutting down.
> The idea is to rather give them a chance to stop themselves. If you
> simply destroy, the state of whatever they where doing, it could be a
> mess.... I mean imagine if one of those threads was backup your dB....
> its half way... how do you stop it?
> You certainly dont want Tomcat to just whack it.....
>
> Have fun....
>
>
>
> ----- Original Message ----- From: "David Delbecq" <de...@oma.be>
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Sent: Wednesday, June 06, 2007 4:55 PM
> Subject: webappclassloader won't get garbage colelcte, need
> suggestions (out of memory)
>
>
>> Hello,
>>
>> Trying to locate memory leak issues (not garbage collected classes &
>> classloader) i noticed this huge problem:
>>
>> My webapp uses libraries that spawn helper Threads, using the default
>> ThreadGroup. Those Helper Thread are subclasses of java.lang.Thread that
>> override the run(). After stopping properly all those Threads at webapp
>> shutdown (they have all existed from run() ), it seems those Threads are
>> still referenced by the main ThreadGroup. Shouldn't tomcat clean the
>> ThreadGroup when a webapp is undeployed? This indirect directional link
>> between a system ThreadGroup and WebappClassLoader loader classes
>> prevents garbage collecting.
>>
>> Am currently working on a context listener in my webapp that will clean
>> it at destroy time, but am pretty sure this should be the container's
>> job.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk along side mod_dir -- How to get PHP to be seen as a default
page
Posted by Mark Thomas <ma...@apache.org>.
Dan D. wrote:
> Hello,
<snip />
When starting a new thread (ie sending a message to the list about a
new topic) please do not reply to an existing message and change the
subject line. This is known as thread hijacking and to many of the
list archiving services and mail clients used by list subscribers this
makes your new message appear as part of the old thread. This makes it
harder for other users to find relevant information when searching the
lists.
It should also be noted that many list subscribers automatically
ignore any messages that hijack another thread.
The correct procedure is to create a new message with a new subject.
This will start a new thread.
Thanks,
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
mod_jk along side mod_dir -- How to get PHP to be seen as a default page
Posted by "Dan D." <da...@dubomail.com>.
Hello,
First the versions:
Apache : 1.3.33
Tomcat: 6.0.13
mod_jk: 1.2.23
I am currently working on upgrading our environment to a newer version of
Tomcat and mod_jk, and seem to be running into an issue with mod_jk and
mod_dir. More specifically, the issue I am running into is the default file
list.
As I understand, it is intended behavior for the Apache DirectoryIndex
directive to be more or less ignored, and instead the <welcome-file-list />
directive in web.xml is used to determine which files are loaded and in
which order by default.
Now, the issue I run into is that I do not know in advance what our
customers will be loading on their site. There is a very real possibility
that they may have an index.php file, which we want to have load first.
This is something that I want to have Apache load, instead of Tomcat
attempting to parse it, since we run php in a sandbox (suPHP).
Everything I have attempted, ends up basically the same when attempting to
view a site by the hostname only (ie., http://hostname.tld/)
If I add
<welcome-file>index.php</welcome-file>
to the <welcome-file-list> in my web.xml, it simply asks me to download the
php file, instead of it being parsed by Apache.
If it is not in the welcome-file-list, it simply goes to the next one that
is (index.html) and is still parsed by Tomcat, not Apache.
The related Apache Jk settings are as follows:
In addition, after the mod_jk include, but prior to any Jk settings, I have
the following:
LoadModule dir_module libexec/mod_dir.so
LoadModule jk_module libexec/mod_jk.so
<IfModule mod_dir.c>
DirectoryIndex default.html default.htm index.php index.shtml index.html
index.htm home.html home.htm welcome.html index.jsp
</IfModule>
<Location "/">
SetEnvIf REQUEST_URI ^/(.*)/*.php$ no-jk
SetEnvIf REQUEST_URI ^/(.*)/*.html$ no-jk
</Location>
JkWorkersFile /web/conf/workers.properties
JkUnMount /*.php local
JkMountFile /web/conf/uriworkermap.properties
JkLogFile /web/logs/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %U %T"
The contents of workers.properties are:
worker.list=local,jkstatus
# Set properties for worker1 (ajp13)
worker.local.type=ajp13
worker.local.host=localhost
worker.local.port=8009
worker.local.lbfactor=1
worker.jkstatus.type=status
worker.local.mount=/ /*
The contents of uriworkermap.properties are:
#exclude extensions
!*.html=local
!*.php=local
I understand that there are a few settings that are redundant, but I have
tried every "don't touch php, tomcat" setting I can find, and it is still
attempting to parse it.
Also a thing to note. This only happens when attempting to view the default
page. If I browse directly to http://hostname.tld/index.php, it works fine.
So, my question is, how do I either prevent Tomcat from handling these
requests, or tell it to pass them back to Apache if it doesn't know what to
do with them?
I thank you for your time and help in this matter,
Dan D.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: webappclassloader won't get garbage colelcte, need suggestions (out of memory)
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
No, imagine if you used a thread to say send an email.
The webapp is done, tomcat is idling and it whacks your thread that hasnt
done the email yet.
You see it in normal java apps as well, ie if a thread is still busy and you
close the app, if you look at the processes, the thread is keeping it alive.
You have to signal your thread, so perhaps when the class that started the
threads is destroyed, it sets a variable that the threads can see, and they
start shutting down.
The idea is to rather give them a chance to stop themselves. If you simply
destroy, the state of whatever they where doing, it could be a mess.... I
mean imagine if one of those threads was backup your dB.... its half way...
how do you stop it?
You certainly dont want Tomcat to just whack it.....
Have fun....
----- Original Message -----
From: "David Delbecq" <de...@oma.be>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Wednesday, June 06, 2007 4:55 PM
Subject: webappclassloader won't get garbage colelcte, need suggestions (out
of memory)
> Hello,
>
> Trying to locate memory leak issues (not garbage collected classes &
> classloader) i noticed this huge problem:
>
> My webapp uses libraries that spawn helper Threads, using the default
> ThreadGroup. Those Helper Thread are subclasses of java.lang.Thread that
> override the run(). After stopping properly all those Threads at webapp
> shutdown (they have all existed from run() ), it seems those Threads are
> still referenced by the main ThreadGroup. Shouldn't tomcat clean the
> ThreadGroup when a webapp is undeployed? This indirect directional link
> between a system ThreadGroup and WebappClassLoader loader classes
> prevents garbage collecting.
>
> Am currently working on a context listener in my webapp that will clean
> it at destroy time, but am pretty sure this should be the container's job.
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: was anyone able to change his/her email address in this list
Posted by Gregor Schneider <rc...@googlemail.com>.
Besides:
Why don't you use a filter in your mail-program?
if sender == users@tomcat.apache.org
move mail to folder tomcat_user-lst
Works great for me, although I'm using GoogleMail to read & post
Cheers
Gregor
--
what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: was anyone able to change his/her email address in this list
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Pid [mailto:p@pidster.com]
> Subject: Re: was anyone able to change his/her email address
> in this list
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
Note that the above can only be done from the registered e-mail address.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: was anyone able to change his/her email address in this list
Posted by Pid <p...@pidster.com>.
What did you try?
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
You'll probably receive a confirmation message that you need to action.
p
Abdelmonaam Kallali wrote:
> I've tried that but didn't work
>
> Abdelmonaam KALLALI
> Test Specialist
> DragonWave Inc
> 411 Legget Dr
> Phone :613-599 9991 ext 275
>
> -----Original Message-----
> From: Gregor Schneider [mailto:rc46fi@googlemail.com]
> Sent: Wednesday, June 06, 2007 12:09 PM
> To: Tomcat Users List
> Subject: Re: was anyone able to change his/her email address in this list
>
> 1. unsubscribe with your old email-address
> 2. subscribe with your new email-address
>
> Gregor
Re: was anyone able to change his/her email address in this list
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Abdelmonaam,
Really? It didn't work? How did you try to unsubscribe? How did you try
to subscribe?
I see a lot of folks who have trouble subscribing or un-subscribing from
mailing lists... I have never had a single problem. (And I use gnupg,
which often causes some problems with poorly written email programs).
- -chris
Abdelmonaam Kallali wrote:
> I've tried that but didn't work
>
> Abdelmonaam KALLALI
> Test Specialist
> DragonWave Inc
> 411 Legget Dr
> Phone :613-599 9991 ext 275
>
> -----Original Message-----
> From: Gregor Schneider [mailto:rc46fi@googlemail.com]
> Sent: Wednesday, June 06, 2007 12:09 PM
> To: Tomcat Users List
> Subject: Re: was anyone able to change his/her email address in this list
>
> 1. unsubscribe with your old email-address
> 2. subscribe with your new email-address
>
> Gregor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGaBxc9CaO5/Lv0PARAj0YAJ4vtMCnJgzDxmZblpSNQX5y8r/BTACeI7e3
+0I1yOBRxtwEdlz5Q0Lert8=
=Rqz1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: was anyone able to change his/her email address in this list
Posted by Abdelmonaam Kallali <ak...@dragonwaveinc.com>.
I've tried that but didn't work
Abdelmonaam KALLALI
Test Specialist
DragonWave Inc
411 Legget Dr
Phone :613-599 9991 ext 275
-----Original Message-----
From: Gregor Schneider [mailto:rc46fi@googlemail.com]
Sent: Wednesday, June 06, 2007 12:09 PM
To: Tomcat Users List
Subject: Re: was anyone able to change his/her email address in this list
1. unsubscribe with your old email-address
2. subscribe with your new email-address
Gregor
--
what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: was anyone able to change his/her email address in this list
Posted by Gregor Schneider <rc...@googlemail.com>.
1. unsubscribe with your old email-address
2. subscribe with your new email-address
Gregor
--
what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
was anyone able to change his/her email address in this list
Posted by Abdelmonaam Kallali <ak...@dragonwaveinc.com>.
Hi All
Was anyone able to change his/her email address in this list?
I'm having hard time sorting Tomcat users list from my work emails and it is
taking a bit of my work time can anyone help?
Thanks
Abdelmonaam KALLALI
Test Specialist
DragonWave Inc
411 Legget Dr
Phone :613-599 9991 ext 275
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: webappclassloader won't get garbage colelcte, need suggestions (outof memory)
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David Delbecq [mailto:delbd+jakarta@oma.be]
> Subject: webappclassloader won't get garbage colelcte, need
> suggestions (outof memory)
>
> Shouldn't tomcat clean the ThreadGroup when a webapp
> is undeployed?
It's certainly not the container's job to keep track of threads that it
has no knowledge of. Since your webapp created them, it's up to the
webapp to clean up properly.
I suspect these auxiliary threads are not actually terminating properly,
since the JVM automatically removes terminated threads from the group to
which they belong.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org