Re: Tomcat 6.0.29 using more and more RAM until it collapses?
On 12/11/2010 05:54, Brian wrote: Hi Pid, I did it, but shows no results. Anyway, it was nice to learn about Jconsole. Now I wonder what is the tool I could use to inspect the objets inside my app, and see which ones are using all the memory. Try VisualVM, another JDK6 tool, but a more recent version is available: http://visualvm.dev.java.net/ There are extra plugins available from the Tools menu. You can use profiling on local JVM processes to see which classes are using memory, CPU time. Or take a series of heap dump and import, examine them. p -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Thursday, November 11, 2010 03:06 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 11/11/2010 18:54, Brian wrote: I don't think my app is taking all this RAM, because when I restart it, the RAM usage doesn't go down. It does only if I restart Tomcat itself, instead of my app running there. Yes, this is a classic sign of a problem with the app. Reboot Tomcat, restart your app a couple of times (this bit is important). Connect to the Tomcat instance using JConsole, navigate the MBeans, to Catalina Hosts (your hostname), then select the Operations tab, under which you'll see a button called findReloadContextMemoryLeaks. Push the button. It will return a list of app names if Tomcat can detect ones with memory leaks. NB No results doesn't necessarily mean your app isn't leaking. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: question for next Tomcat 6.0 release
On 03/11/2010 15:06, Okubo, Yasushi (TSD) wrote: Hi I am wondering if someone knows about release scheduled for next version : Tomcat v6.0.30 or any release schedule in next six month. I am currently running tomcat 6.0.26 [my development box with single instance configuration] and 6.0.28 on my test environment [two node cluster] and it is getting time to consider to upgrade to the latest. You got no answer because there isn't a fixed release schedule. It's been a few months (July) since there was a release though, so we might see one before the end of the year. (Hint hint, to any devs reading this). p I do not think we will test tomcat 7 at this moment. Thanks, yasushi ### This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ### 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: question for next Tomcat 6.0 release
On 12/11/2010 08:55, Pid wrote: On 03/11/2010 15:06, Okubo, Yasushi (TSD) wrote: Hi I am wondering if someone knows about release scheduled for next version : Tomcat v6.0.30 or any release schedule in next six month. I am currently running tomcat 6.0.26 [my development box with single instance configuration] and 6.0.28 on my test environment [two node cluster] and it is getting time to consider to upgrade to the latest. You got no answer because there isn't a fixed release schedule. It's been a few months (July) since there was a release though, so we might see one before the end of the year. (Hint hint, to any devs reading this). :) Jean-Frederic (the current 6.0.x) release manager indicated at ApacheCon last week that this was on his todo list so a release between now and then end of the year is probable. Mark p I do not think we will test tomcat 7 at this moment. Thanks, yasushi ### This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ### - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using mod_jk in cluster environment responds HTTP 500
Greeting, I've one apache and two tomcat installed in my server. The communication happens using AJP 1.3. I'm using the jkmanager URL to activate/deactivate the tomcat instances. Also, I'm making sure atleast one of the two tomcat instance is up when other one is down. The problem is sometimes the client request does go to deactivated tomcat instance resulting in HTTP 500 error. I want the request to be redirected only to the active tomcat instance and not the deactivated one. Please suggest how can I do this. Regards, rikslovein -- View this message in context: http://old.nabble.com/Using-mod_jk-in-cluster-environment-responds-HTTP-500-tp30198809p30198809.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using mod_jk in cluster environment responds HTTP 500
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rikslovein, On 11/12/2010 7:19 AM, rikslovein wrote: I've one apache and two tomcat installed in my server. The communication happens using AJP 1.3. I'm using the jkmanager URL to activate/deactivate the tomcat instances. Also, I'm making sure atleast one of the two tomcat instance is up when other one is down. The problem is sometimes the client request does go to deactivated tomcat instance resulting in HTTP 500 error. I want the request to be redirected only to the active tomcat instance and not the deactivated one. Please suggest how can I do this. Can you post your workers.properties file (minus any secrets) and also your Connector configuration from Tomcat's server.xml file? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdY9oACgkQ9CaO5/Lv0PAt9ACeMGF7xMjQl3oM+qz66LP0cENS mEQAmwZ2pRzawrlcBaOlqOD3tXyES9ap =zsLx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Great advice, thanks I'm using it right now, and I'm also using www.yourkit.com as a trial. My problem is in the Tenured/Gen area. There is where most of the RAM is getting used. Now I need to fin out what Tenured/Gen is about -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 12, 2010 03:49 AM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 12/11/2010 05:54, Brian wrote: Hi Pid, I did it, but shows no results. Anyway, it was nice to learn about Jconsole. Now I wonder what is the tool I could use to inspect the objets inside my app, and see which ones are using all the memory. Try VisualVM, another JDK6 tool, but a more recent version is available: http://visualvm.dev.java.net/ There are extra plugins available from the Tools menu. You can use profiling on local JVM processes to see which classes are using memory, CPU time. Or take a series of heap dump and import, examine them. p -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Thursday, November 11, 2010 03:06 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 11/11/2010 18:54, Brian wrote: I don't think my app is taking all this RAM, because when I restart it, the RAM usage doesn't go down. It does only if I restart Tomcat itself, instead of my app running there. Yes, this is a classic sign of a problem with the app. Reboot Tomcat, restart your app a couple of times (this bit is important). Connect to the Tomcat instance using JConsole, navigate the MBeans, to Catalina Hosts (your hostname), then select the Operations tab, under which you'll see a button called findReloadContextMemoryLeaks. Push the button. It will return a list of app names if Tomcat can detect ones with memory leaks. NB No results doesn't necessarily mean your app isn't leaking. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Client not able with perform client-cert authentication with Tomcat 6.0.29 on APR
Hi I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP. I changed server.xml as below. ?xml version=1.0 encoding=UTF-8? Server port=8005 shutdown=SHUTDOWN !--APR library loader. Documentation at /docs/apr.html -- Listener SSLEngine=on className=org.apache.catalina.core.AprLifecycleListener / Listener className=org.apache.catalina.core.JasperListener / !-- Prevent memory leaks due to use of particular java/javax APIs-- Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / GlobalNamingResources Resource auth=Container description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory name=UserDatabase pathname=conf/tomcat-users.xml type=org.apache.catalina.UserDatabase / /GlobalNamingResources Service name=Catalina Connector connectionTimeout=2 port=8080 protocol=HTTP/1.1 redirectPort=8443 / Connector SSLCACertificateFile=C:\usr-files\client-cert-ca.crt SSLCertificateFile=C:\usr\tomcat\tomcat.crt SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key SSLCipherSuite=AES128-SHA:DES-CBC3-SHA SSLEnabled=true SSLEngine=on SSLVerifyClient=optional maxThreads=150 port=8443 protocol=HTTP/1.1 scheme=https secure=true sslProtocol=TLS / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine defaultHost=localhost name=Catalina Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase / Host appBase=webapps autoDeploy=true name=localhost unpackWARs=true xmlNamespaceAware=false xmlValidation=false Context docBase=cert path=/cert reloadable=true source=org.eclipse.jst.j2ee.server:cert / Context docBase=crl path=/crl reloadable=true source=org.eclipse.jst.j2ee.server:crl / Context docBase=tdci-2.5.0 path=/tdci-2.5.0 reloadable=true source=org.eclipse.jst.j2ee.server:tdci-2.5.0 / /Host /Engine /Service /Server *My **Java **XML-RPC client thrown exception below:* Exception in thread main java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(OutputRecord.java:283) at com.sun.net.ssl.internal.ssl.OutputRecord.write(OutputRecord.java:272) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:666) at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:584) at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:698) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:624) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:160) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:839) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230) at org.apache.xmlrpc.DefaultXmlRpcTransport.sendXmlRpc(Unknown Source) at org.apache.xmlrpc.XmlRpcClientWorker.execute(Unknown Source) at org.apache.xmlrpc.XmlRpcClient.execute(Unknown Source) at TdciXmlRpcCertAuthClient.requestWebIssuanceKey(TdciXmlRpcCertAuthClient.java:166) at TdciXmlRpcCertAuthClient.main(TdciXmlRpcCertAuthClient.java:63) Please help. Thank you. SamKong Goo
Re: Client not able with perform client-cert authentication with Tomcat 6.0.29 on APR
On 12/11/2010 16:27, Goo Sam Kong wrote:
Hi
I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.
APR/native connector version? SSL re-negotiation wasn't supported until
recently and the CVE-2009-3555 fixes further complicate things.
Connector SSLCACertificateFile=C:\usr-files\client-cert-ca.crt
SSLCertificateFile=C:\usr\tomcat\tomcat.crt
SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key
SSLCipherSuite=AES128-SHA:DES-CBC3-SHA
SSLEnabled=true
SSLEngine=on
SSLVerifyClient=optional
maxThreads=150
port=8443
protocol=HTTP/1.1
scheme=https
secure=true
sslProtocol=TLS /
Is SSLEngine a valid attribute here? I don't see it in the Connector docs.
SSLVerifyClient=optional can (should?) be removed.
Is that SSLCipherSuite compatible with your client? Try removing that
setting until everything else is working.
The following settings are known to work:
Connector
port=8443
protocol=org.apache.coyote.http11.Http11AprProtocol
SSLEnabled=true
maxThreads=150
scheme=https
secure=true
SSLCertificateFile=${catalina.base}/conf/tomcathost-cert.pem
SSLCertificateKeyFile=${catalina.base}/conf/tomcathost-key.pem
SSLCACertificateFile=${catalina.base}/conf/cacert.pem /
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recommendations for (or against) a hardware load balancer
Mark Thomas wrote: On 11/11/2010 14:12, Christopher Schultz wrote: All, I'm looking for a modest load balancer to perform SSL termination and work well with Tomcat's cookie- and URL-based sticky session mechanism. Does anyone have any recommendations? Decent H/W usually cost $$$ If Apache httpd is just as good for an environment that gets thousands of hits per day, not millions, then I'm happy to run using that as well, though maintaining a whole Linux machine just for httpd load-balancing seems like more trouble than it's worth. For that few hits, you might get away with just a VM. Otherwise, let me point you to something : search Google for LEX NEO. These are small disk-less and fan-less boxes, which can have up to at least 3 Ethernet interfaces, and which run Linux fine on a compact flash or other static memory device. We use them as firewalls and for other similar uses. Extremely reliable (2-3 years already with no downtime), low power, noiseless, small, not expensive. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
I found the problem and this time it wasn't my fault! :-) I used a profiler (www.yourkit.com) and took a snapshot of all the objects in the JVM. I found that tons of RAM is being used by images of my delivered http responses. I mean, I have thousands of static HTML pages in my site. It seems that Tomcat is saving their content in the memory, as a cache, in thousands of objects. That was the hardest part, to find out that. Now I wonder where do I configure Tomcat to stop doing this, or at least to reduce the cache. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, November 11, 2010 02:11 PM To: Tomcat Users List Subject: RE: Tomcat 6.0.29 using more and more RAM until it collapses? From: Brian [mailto:bbprefix-m...@yahoo.com] Subject: Tomcat 6.0.29 using more and more RAM until it collapses? I don't think my app is taking all this RAM It is. when I restart it, the RAM usage doesn't go down. Classic symptom of a webapp leaking memory due to holding onto It seems like if Tomcat is leaving garbage in the JVM or something like that. Nope - it's your webapp. Does anybody know what should I do to solve this? Fix your webapp(s). Start with a heap profiler, and look to see what's consuming the space. The problem may also include memory leaks outside of the heap, such as failing to close files, or starting and forgetting about auxiliary threads. Start reading here: http://wiki.apache.org/tomcat/FAQ/Memory http://wiki.apache.org/tomcat/OutOfMemory http://wiki.apache.org/tomcat/MemoryLeakProtection - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
On 12/11/2010 18:13, Brian wrote: I found the problem and this time it wasn't my fault! :-) I wouldn't be so sure about that just yet. I used a profiler (www.yourkit.com) and took a snapshot of all the objects in the JVM. I found that tons of RAM is being used by images of my delivered http responses. I mean, I have thousands of static HTML pages in my site. It seems that Tomcat is saving their content in the memory, as a cache, in thousands of objects. Tomcat's static content cache is 10MB per web application by default. I suspect something else is holding on to those references. Where to the GC roots trace to? That was the hardest part, to find out that. Now I wonder where do I configure Tomcat to stop doing this, or at least to reduce the cache. You need to confirm what is holding on to those references first. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Hi Mark, Besides using Tomcat to serve my app (which itself serves about 600,000 diferent URLs), I also use it to serve static pages (HTML pages stored in the hard disk). I don't know if Tomcat is caching my dinamically generated pages (maybe it is), but for now I would love to stop the cache that stores the static ones. Those static pages are in their own WARs, so they have nothing to do with the java code in my app. Where do I configure Tomcat to stop caching the static pages in memory? This is definitely my problem, I can see clearly the pages in my memory snapshot, and when I let Google crawl my site with more speed, my site (and Tomcat itself, I guess) crashes sooner. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, November 12, 2010 01:19 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 12/11/2010 18:13, Brian wrote: I found the problem and this time it wasn't my fault! :-) I wouldn't be so sure about that just yet. I used a profiler (www.yourkit.com) and took a snapshot of all the objects in the JVM. I found that tons of RAM is being used by images of my delivered http responses. I mean, I have thousands of static HTML pages in my site. It seems that Tomcat is saving their content in the memory, as a cache, in thousands of objects. Tomcat's static content cache is 10MB per web application by default. I suspect something else is holding on to those references. Where to the GC roots trace to? That was the hardest part, to find out that. Now I wonder where do I configure Tomcat to stop doing this, or at least to reduce the cache. You need to confirm what is holding on to those references first. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
On 12/11/2010 18:30, Brian wrote: Hi Mark, Besides using Tomcat to serve my app (which itself serves about 600,000 diferent URLs), I also use it to serve static pages (HTML pages stored in the hard disk). I don't know if Tomcat is caching my dinamically generated pages (maybe it is), but for now I would love to stop the cache that stores the static ones. Those static pages are in their own WARs, so they have nothing to do with the java code in my app. Where do I configure Tomcat to stop caching the static pages in memory? This is definitely my problem, I can see clearly the pages in my memory snapshot, and when I let Google crawl my site with more speed, my site (and Tomcat itself, I guess) crashes sooner. You are missing the point. It is highly unlikely the 10MB per webapp cache is causing problems given that you previously states that there are only two WAR files here. So I'll ask my question again: Where to the GC roots for those objects trace to? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Well, maybe you can help me to make an interpretation. I'm using Yourkit, and this this what I see. The most RAM is used by byte arrays. If I choose this entry in the list of classes, below you will see a list of objects. If you choose the first one and check the content (400kb), it is the image of a static HTML page. I really don't know how to find out to which classes do these bytes belong to, or their relationship with the garbage collector, but I can see that they use a lot of RAM. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, November 12, 2010 01:38 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 12/11/2010 18:30, Brian wrote: Hi Mark, Besides using Tomcat to serve my app (which itself serves about 600,000 diferent URLs), I also use it to serve static pages (HTML pages stored in the hard disk). I don't know if Tomcat is caching my dinamically generated pages (maybe it is), but for now I would love to stop the cache that stores the static ones. Those static pages are in their own WARs, so they have nothing to do with the java code in my app. Where do I configure Tomcat to stop caching the static pages in memory? This is definitely my problem, I can see clearly the pages in my memory snapshot, and when I let Google crawl my site with more speed, my site (and Tomcat itself, I guess) crashes sooner. You are missing the point. It is highly unlikely the 10MB per webapp cache is causing problems given that you previously states that there are only two WAR files here. So I'll ask my question again: Where to the GC roots for those objects trace to? Mark - To unsubscribe, e-mail: mailto:users-unsubscr...@tomcat.apache.org users-unsubscr...@tomcat.apache.org For additional commands, e-mail: mailto:users-h...@tomcat.apache.org users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
On 12/11/2010 18:59, Brian wrote: Well, maybe you can help me to make an interpretation. I'm using Yourkit, and this this what I see. The most RAM is used by byte arrays. If I choose this entry in the list of classes, below you will see a list of objects. If you choose the first one and check the content (400kb), it is the image of a static HTML page. I really don't know how to find out to which classes do these bytes belong to, or their relationship with the garbage collector, but I can see that they use a lot of RAM. Look in the YourKit docs for how to trace the GC roots. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
From: Brian [mailto:bbprefix-m...@yahoo.com] Subject: RE: Tomcat 6.0.29 using more and more RAM until it collapses? I'm using Yourkit, and this this what I see. But we can't, since the mailing list strips attachments. - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Oh, I think I found what you were asking, the path to the GC root: org.apache.naming.resources.FileDirContext$FileResource org.apache.naming.resources.CacheEntry org.apache.naming.resources.CacheEntry[XXX] org.apache.naming.resources.ResourceCache org.apache.naming.resources.ProxyDirContext etc etc etc -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, November 12, 2010 01:38 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 12/11/2010 18:30, Brian wrote: Hi Mark, Besides using Tomcat to serve my app (which itself serves about 600,000 diferent URLs), I also use it to serve static pages (HTML pages stored in the hard disk). I don't know if Tomcat is caching my dinamically generated pages (maybe it is), but for now I would love to stop the cache that stores the static ones. Those static pages are in their own WARs, so they have nothing to do with the java code in my app. Where do I configure Tomcat to stop caching the static pages in memory? This is definitely my problem, I can see clearly the pages in my memory snapshot, and when I let Google crawl my site with more speed, my site (and Tomcat itself, I guess) crashes sooner. You are missing the point. It is highly unlikely the 10MB per webapp cache is causing problems given that you previously states that there are only two WAR files here. So I'll ask my question again: Where to the GC roots for those objects trace to? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 11/12/2010 11:19 AM, Brian wrote: Great advice, thanks I'm using it right now, and I'm also using www.yourkit.com as a trial. My problem is in the Tenured/Gen area. There is where most of the RAM is getting used. Now I need to fin out what Tenured/Gen is about Would you mind taking a look back at my message from yesterday? I asked some questions that might be able to significantly reduce the effort you expend during your search. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdkuUACgkQ9CaO5/Lv0PAaSgCfazR0EQlmQ8HgreOnxXJHjDlq uXoAnjMQKBEEer2Q5DYIhilqcuwdyTzk =VpG0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
On 12/11/2010 19:12, Brian wrote: Oh, I think I found what you were asking, the path to the GC root: org.apache.naming.resources.FileDirContext$FileResource org.apache.naming.resources.CacheEntry org.apache.naming.resources.CacheEntry[XXX] org.apache.naming.resources.ResourceCache org.apache.naming.resources.ProxyDirContext etc etc etc OK, that is indeed Tomcat's static file cache. Given you only have two WARs and the default cache size is 10MB per WAR I am struggling to see how this could be causing an OOME. Anyway, the settings for this are on the Context element. The simplest way to disable static file caching everywhere is to add the following to the Context element in CATALINA_BASE/conf/context.xml cachingAllowed=false Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 11/12/2010 2:12 PM, Brian wrote: Oh, I think I found what you were asking, the path to the GC root: org.apache.naming.resources.FileDirContext$FileResource org.apache.naming.resources.CacheEntry org.apache.naming.resources.CacheEntry[XXX] org.apache.naming.resources.ResourceCache org.apache.naming.resources.ProxyDirContext etc etc etc That etc. is important information. Keep going. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdk40ACgkQ9CaO5/Lv0PCbeQCgvQIBv7AHHN4kuQMiZaN17hpu oSoAnRK4VoH++sZS4/13dqLQmUXO95ki =Ev1I -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 11/12/2010 2:12 PM, Brian wrote: Oh, I think I found what you were asking, the path to the GC root: org.apache.naming.resources.FileDirContext$FileResource org.apache.naming.resources.CacheEntry org.apache.naming.resources.CacheEntry[XXX] org.apache.naming.resources.ResourceCache org.apache.naming.resources.ProxyDirContext etc etc etc That etc. is important information. Keep going. Also, a given object may be reachable from more than one root, so show them all. - 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.
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Byte[401494] = {10,10,10,10,.} This
contains the whole 400KB HTML code
binaryContent oforg.apache.naming.resources.FileDirContext$FileResource
resource of org.apache.naming.resources.CacheEntry
[2]of org.apache.naming.resources.CacheEntry[6]
Cache oforg.apache.naming.resources.ResourceCache
Cache of org.apache.naming.resources.ProxyDirContext
Value of java.util.Hashtable$Entry
[20]ofjava.util.Hashtable$Entry[47]
Table of java.util.Hashtable
clBindings oforg.apache.naming.resources.DirContextURLStreamHandler
[275 of java.lang.Object[640]
elementData of java.util.Vector
classes of org.apache.catalina.loader.StandardClassLoader
contextClassLoader of java.lang.Thread [Stack Local, Thread] http-8080-52
native ID: xx
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, November 12, 2010 02:21 PM
To: Tomcat Users List
Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 11/12/2010 2:12 PM, Brian wrote:
Oh, I think I found what you were asking, the path to the GC root:
org.apache.naming.resources.FileDirContext$FileResource
org.apache.naming.resources.CacheEntry
org.apache.naming.resources.CacheEntry[XXX]
org.apache.naming.resources.ResourceCache
org.apache.naming.resources.ProxyDirContext
etc
etc
etc
That etc. is important information. Keep going.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzdk40ACgkQ9CaO5/Lv0PCbeQCgvQIBv7AHHN4kuQMiZaN17h
pu
oSoAnRK4VoH++sZS4/13dqLQmUXO95ki
=Ev1I
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Hi Chris, I saved your email and hadn't replied yet. Here are my responses, thanks! -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, November 11, 2010 02:39 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? Brian, On 11/11/2010 1:54 PM, Brian wrote: I don't think my app is taking all this RAM, because when I restart it, the RAM usage doesn't go down. That doesn't necessarily mean that your webapp isn't using all that heap space: it's very easy for a webapp to do something foolish and cause all of it's used memory to stay active even after a webapp restart. Yes, now I know that. I disagree with Ben's comment about database connections: there are faster ways to bust your heap than leaking database connections. If you /are/ using Tomcat's container-managed DataSource (which I highly recommend), you should enable all of the abandoned resource tracking features to help fix any resource leaks that you may have there. Well, the database relation with my code is not the problem, I'm using a pool and it works great. I don’t know for what else should I use the DataSource. I agree with Chuck's assessment, but there may be some questions we can ask to help lead you down the right path when using tools such as memory profilers. 0. What kind of OOME are you suffering? Please post any messages that you get when your heap busts. Specifically, is this a regular heap exhaustion or a PermGen exhaustion? Good question, but I can't answer that. I think I lost my logs. :-( I will search for them again. But I could use the profiler now and responde whatever you would like to ask about how is it behaving now. 1. Are you seeing any messages in catalina.out when you undeploy of the form your webapp likely has a memory leak? Tomcat 6.0.x has some nice checks on undeploy to see if your webapp is leaking some specific things like threads, etc. Yeah, I have seen those lately. 2. Are you re-starting your webapp a lot while Tomcat remains running? Failure to perform some clean-up during webapp unload can cause your entire set of classes loaded in the old webapp to stay in the PermGen space forever. No, I don’t restart them frequently. But I do redeploy them frequently, in the past I did it deleting the WAR in the directly and uploading a new one, now I'm suing the Tmocat Manager do undeploy and deploy again. 3. Are you using any caching mechanism in your webapp? Perhaps it needs to be tuned. You should probably check out what's in your application scope: you may have things you didn't expect. I do have some caches in my objects. For example, the ir an object called BrandsManager which has methods like getBrands(), getBrand(int id), insertBrand and so on. The getBrands() method goes to the database only the first time, and then creates a LinkedList with the data. But I don't think this kind of caching is the problem, they consume a minimal amount of memory. 4. Are you using HttpSession for anything bulky? It's possible that you are leaking memory with lots of sessions. When a webapp is stopped, though, all session should be purged and if you have session persistence, they should all come back and take up the same amount of memory. This is a long-shot, but low-hanging fruit. No, I don’t store anything big in the sessions. I just store some strings in them. Nothing serious. How do I know if I have session persistence? You can get a lot of mileage out of a tool like jmap which comes with the JDK (and JRE?): you can get a heap histogram and look at things that are taking up a lot of space. If you find that you have several tens of megabytes of foo.bar.Baz classes, then you can look at your app to see where you heavy uses of those classes are. I'm already using yourkit, which I guess is even better. To understand #2 a bit better, see Mark's presentation from this year's ApacheCon NA: http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks- 60mins.pdf I will now!! It's worth a read to understand how simple things like using a logging library can cause PermGen exhaustion after several webapp redeploy operations. Well, I'm using the Tomcat log indeed. And I also saw a lot of memory being used by that! But more memory is being used by the cached static pages, so I guess I should start with that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Ok, I will do that now! I have taken another snapshot of the JVM a few minutes ago. Now I also see that 160MB are being used by org.apache.jasper.runtime.BodyContextImpl. This contains images of my DYNAMIC pages! This is the path: Org.apache.jasper.runtime.BodyContentIml [1] of org.apache.jasper.runtime.BodyContentImpl[2] Outs of org.apache.jasper.runtime.PageContextImpl [0] of javax.servlet.jsp.PageContext[8] Pool of org.apache.jasper.runtime.JspFactoryImpl$PageContextPool Value of java.lang.ThreadLocal$ThreadLocalMap$Entry [8] of java.lang.ThreadLocal$ThreadLocalMap$Entry[16] Table of java.lang.ThreadLocal$ThreadLocalMap threadLocals of java.lang.Thread [Stack Local, Thread] http-8080-18 native ID: XX -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, November 12, 2010 02:19 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 12/11/2010 19:12, Brian wrote: Oh, I think I found what you were asking, the path to the GC root: org.apache.naming.resources.FileDirContext$FileResource org.apache.naming.resources.CacheEntry org.apache.naming.resources.CacheEntry[XXX] org.apache.naming.resources.ResourceCache org.apache.naming.resources.ProxyDirContext etc etc etc OK, that is indeed Tomcat's static file cache. Given you only have two WARs and the default cache size is 10MB per WAR I am struggling to see how this could be causing an OOME. Anyway, the settings for this are on the Context element. The simplest way to disable static file caching everywhere is to add the following to the Context element in CATALINA_BASE/conf/context.xml cachingAllowed=false Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 11/12/2010 3:02 PM, Brian wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, November 11, 2010 02:39 PM I agree with Chuck's assessment, but there may be some questions we can ask to help lead you down the right path when using tools such as memory profilers. 0. What kind of OOME are you suffering? Please post any messages that you get when your heap busts. Specifically, is this a regular heap exhaustion or a PermGen exhaustion? Good question, but I can't answer that. I think I lost my logs. :-( I will search for them again. But I could use the profiler now and responde whatever you would like to ask about how is it behaving now. I think you already answered this elsewhere: you're filling-up your Tenured generation and/or PermGen. Keep an eye on PermGen: if it's filling up after your 60 URLs (that's a /lot/ IMO) have all been hit, then you might have a redeployment problem. 1. Are you seeing any messages in catalina.out when you undeploy of the form your webapp likely has a memory leak? Tomcat 6.0.x has some nice checks on undeploy to see if your webapp is leaking some specific things like threads, etc. Yeah, I have seen those lately. Read them, and try to fix them. ;) 2. Are you re-starting your webapp a lot while Tomcat remains running? Failure to perform some clean-up during webapp unload can cause your entire set of classes loaded in the old webapp to stay in the PermGen space forever. No, I don’t restart them frequently. But I do redeploy them frequently, in the past I did it deleting the WAR in the directly and uploading a new one, now I'm suing the Tmocat Manager do undeploy and deploy again. Semantics. You are stopping your webapp and starting it again, with or without an update to the WAR file. It's actually the ungraceful webapp stop that kills you, not the fact that you start up again or whether it's a restart or a redeploy. If your webapp doesn't clean-up, the WebappClassLoader can stay in memory forever. In fact, that's a good test: search your memory snapshot for instances of WebappClassLoader. There's a boolean in each one (active I think) that tells you if it's active. Force a couple of full GCs, then see how many of them are still around. If you have more than 1+webapp count (I think you get one for free plus one for each webapp deployed) then the old, undeployed webapps are still sitting around in memory. If that's the case, then you are filling-up your PermGen with useless java.lang.Class instances. I'm not sure how Tomcat expires it's caches, but it might also be keeping those cached static files around with the WebappClassLoader, too. Double whammy. 3. Are you using any caching mechanism in your webapp? Perhaps it needs to be tuned. You should probably check out what's in your application scope: you may have things you didn't expect. I do have some caches in my objects. For example, the ir an object called BrandsManager which has methods like getBrands(), getBrand(int id), insertBrand and so on. The getBrands() method goes to the database only the first time, and then creates a LinkedList with the data. But I don't think this kind of caching is the problem, they consume a minimal amount of memory. It's always a good idea to double-check. 4. Are you using HttpSession for anything bulky? It's possible that you are leaking memory with lots of sessions. When a webapp is stopped, though, all session should be purged and if you have session persistence, they should all come back and take up the same amount of memory. This is a long-shot, but low-hanging fruit. No, I don’t store anything big in the sessions. I just store some strings in them. Nothing serious.How do I know if I have session persistence? You get it for free if you use the standard manager: it will persist sessions to the disk when Tomcat stops, and re-load them when Tomcat comes back up. This is not session persistence like using a DbStore where all your session data goes to a db or anything like that. It's worth a read to understand how simple things like using a logging library can cause PermGen exhaustion after several webapp redeploy operations. Well, I'm using the Tomcat log indeed. And I also saw a lot of memory being used by that! But more memory is being used by the cached static pages, so I guess I should start with that. Tomcat's log shouldn't be using any noticeable amount of memory. The only static file you mentioned was a 400KiB file, which is only 4% of the default cache size of 10MiB. Are you seeing /lots/ of those files? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdpycACgkQ9CaO5/Lv0PDvJgCfUHYFH2uP/5gYKrb84Y/N/SoN LZEAn2hjU3bjQqx/6+6OdPVdexd6mkkX =dPtI
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
From: Brian [mailto:bbprefix-m...@yahoo.com] Subject: RE: Tomcat 6.0.29 using more and more RAM until it collapses? Now I also see that 160MB are being used by org.apache.jasper.runtime.BodyContextImpl. There are a couple of system properties you can set to control this: org.apache.jasper.runtime.JspFactoryImpl.USE_POOL org.apache.jasper.runtime.JspFactoryImpl.POOL_SIZE Look here for the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RequestDumperFilter improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I would like to propose a new feature for the RequestDumperFilter that is similar to the AccessLogValve's condition setting, except that it is logically opposite: it would be nice to allow a Filter ahead of the RequestDumperFilter in the chain to flag the request as dump-able instead of having to clear-out a flag: presumably, the act of conditionally dumping a request is rare and so the semantics seem reasonable to work opposite to AccessLogValve's condition. So, I can submit a patch that does this but the question is what to call the configuration attribute. I have several options: 1. condition. This may cause confusion as it acts the opposite way to AccessLogValve's condition. 2. ifSet or even if 3. Give the user a choice: ifSet /and/ ifUnset (or both!) Does anyone care either way? Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdqLcACgkQ9CaO5/Lv0PBk+wCcDDeUubB+EWMTIUhNR/TRNe1h JMcAoIMVDVoj2BtK3VTauD3zlAxfWTf6 =vApy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.29 using more and more RAM until it collapses?
Hello Brian, maybe I missed half of the communication, but from the other half I got the feeling that you are shooting in the dark. Heap dumps are hard to decipher especially if the internals seems to be unknown ;-) When hunting a memory leak I setup a cron job that performs the same task once an hour: jmap -heap:live pid file-with-timestamp.heap jmap -histo:live pid file-with-timestamp.histo the jmap histogramm contains all objects in your vm and their cumulated space. by comparing two of them taken in 30 or 60 minutes you can determine which objects are actually increasing numbers or size. With that knowledge analyzing heap dumps can be performed much faster and easier. Keep in mind that analyzing mem leaks that lead to outofmemory after the oome occured is twice as hard as shortly before . regards Leon P.S. I have a small tool that creates a diff of two subsequent histograms, i can share it if you need it. P.P.S. jmap is a standart java tool. Another standart java tool - jhat can theoretically analyze a heap dump based on a baseline heapdump taken previously. On Fri, Nov 12, 2010 at 9:44 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Brian [mailto:bbprefix-m...@yahoo.com] Subject: RE: Tomcat 6.0.29 using more and more RAM until it collapses? Now I also see that 160MB are being used by org.apache.jasper.runtime.BodyContextImpl. There are a couple of system properties you can set to control this: org.apache.jasper.runtime.JspFactoryImpl.USE_POOL org.apache.jasper.runtime.JspFactoryImpl.POOL_SIZE Look here for the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Hi Chris, I will answer everything here: - In my Heap Memory, the Eden Space is barely used (10MB right now). The survivor space is even less used (1MB right now). But the Tenured Gen space has 120MB right now! In fact, when my JVM start to eat houndreds of MB, most of that goes to the Tenured Gen. Why is that? I would like to know. The perm gen is using 22MB right now, which is not a lot so I guess it is normal. - From now on, when I stop an application, I will check if that left a memory leak. I guess I can do that with the new buton on the Tmcat Manager. - I suspect what is the problem when I stop my app: It is a website, so about 30 humans on average are making requests at any time, and the crawlers (specially Googlebot) are doing it as well. Maybe if I stop it when a request was coming, that makes the licking because maybe some class loaders are doing somethin while I'm asking to stop the app. What do you think about this? - I will check the WebappClassLoader issue, thanks for the tip. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, November 12, 2010 03:44 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 11/12/2010 3:02 PM, Brian wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, November 11, 2010 02:39 PM I agree with Chuck's assessment, but there may be some questions we can ask to help lead you down the right path when using tools such as memory profilers. 0. What kind of OOME are you suffering? Please post any messages that you get when your heap busts. Specifically, is this a regular heap exhaustion or a PermGen exhaustion? Good question, but I can't answer that. I think I lost my logs. :-( I will search for them again. But I could use the profiler now and responde whatever you would like to ask about how is it behaving now. I think you already answered this elsewhere: you're filling-up your Tenured generation and/or PermGen. Keep an eye on PermGen: if it's filling up after your 60 URLs (that's a /lot/ IMO) have all been hit, then you might have a redeployment problem. 1. Are you seeing any messages in catalina.out when you undeploy of the form your webapp likely has a memory leak? Tomcat 6.0.x has some nice checks on undeploy to see if your webapp is leaking some specific things like threads, etc. Yeah, I have seen those lately. Read them, and try to fix them. ;) 2. Are you re-starting your webapp a lot while Tomcat remains running? Failure to perform some clean-up during webapp unload can cause your entire set of classes loaded in the old webapp to stay in the PermGen space forever. No, I don t restart them frequently. But I do redeploy them frequently, in the past I did it deleting the WAR in the directly and uploading a new one, now I'm suing the Tmocat Manager do undeploy and deploy again. Semantics. You are stopping your webapp and starting it again, with or without an update to the WAR file. It's actually the ungraceful webapp stop that kills you, not the fact that you start up again or whether it's a restart or a redeploy. If your webapp doesn't clean-up, the WebappClassLoader can stay in memory forever. In fact, that's a good test: search your memory snapshot for instances of WebappClassLoader. There's a boolean in each one (active I think) that tells you if it's active. Force a couple of full GCs, then see how many of them are still around. If you have more than 1+webapp count (I think you get one for free plus one for each webapp deployed) then the old, undeployed webapps are still sitting around in memory. If that's the case, then you are filling-up your PermGen with useless java.lang.Class instances. I'm not sure how Tomcat expires it's caches, but it might also be keeping those cached static files around with the WebappClassLoader, too. Double whammy. 3. Are you using any caching mechanism in your webapp? Perhaps it needs to be tuned. You should probably check out what's in your application scope: you may have things you didn't expect. I do have some caches in my objects. For example, the ir an object called BrandsManager which has methods like getBrands(), getBrand(int id), insertBrand and so on. The getBrands() method goes to the database only the first time, and then creates a LinkedList with the data. But I don't think this kind of caching is the problem, they consume a minimal amount of memory. It's always a good idea to double-check. 4. Are you using HttpSession for anything bulky? It's possible that you are leaking memory with lots of sessions. When a webapp is stopped, though, all session should be purged and if you have session persistence,
7.0.4 problem
Centos 5.5 Linux x64 Mysql connector j 5.1.13 Tomcat 7.0.4 w/apr ajp Mysql cluster 7.1.3 Jdk 1.6.0_21 x64 Anybody aware of any problems with this combination? Using jmeter to load test my servlet, i see mysql threads held up indefinately until i get a 'Too many connections' error from mysql. Ajp threads all go back to Waiting according to visualvm. I have had no such problems with 7.0.2 Thanks, -Tony
Re: RequestDumperFilter improvement
On 12.11.2010 21:51, Christopher Schultz wrote: 1. condition. This may cause confusion as it acts the opposite way to AccessLogValve's condition. 2. ifSet or even if 3. Give the user a choice: ifSet /and/ ifUnset (or both!) I like no. 3, to have it both. It's clear and flexible. BTW, it would alse be usefull replacement for AccessLogValve's condition. Regards, Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Hi Mark, Chris, and all the gurus, I haven't applied this change yet, but something good is happening: Right now, my Tomcat installation is running fine! So given that I havent made any changes to my code, I guess my problem is that sometimes when I stop my website, something goes wrong and not al the resources get liberated. I had noticed some warnings about that indeed. So I guess my problem was not the static/dynamic pages cache as I thought when using the profiler, or they way the DBMS is handled, or any other issue in my programming. As you said from the beginning, when you said that the 10MB cache should not be a problem. So now, given that right now the server is runnning fine, I guess I should concentrate on the problem that sometimes happen when stopping my website. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, November 12, 2010 02:19 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses? On 12/11/2010 19:12, Brian wrote: Oh, I think I found what you were asking, the path to the GC root: org.apache.naming.resources.FileDirContext$FileResource org.apache.naming.resources.CacheEntry org.apache.naming.resources.CacheEntry[XXX] org.apache.naming.resources.ResourceCache org.apache.naming.resources.ProxyDirContext etc etc etc OK, that is indeed Tomcat's static file cache. Given you only have two WARs and the default cache size is 10MB per WAR I am struggling to see how this could be causing an OOME. Anyway, the settings for this are on the Context element. The simplest way to disable static file caching everywhere is to add the following to the Context element in CATALINA_BASE/conf/context.xml cachingAllowed=false Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: 7.0.4 problem
From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Subject: 7.0.4 problem Using jmeter to load test my servlet, i see mysql threads held up indefinately until i get a 'Too many connections' error from mysql. Can you take a thread dump or three and see what everyone's stuck on? - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
