tools for Memory leaks
Hi, I'm looking for a free tool to monitor my application on Tomcat 5.0.28? I don't see any changes in memory use on RH9 - but the load is too low. What I'd like to test: - high load - potential memory leaks - etc. I'd rather to have a tool which have a minimum impact on performance, but any tool will be fine for now. Thank, Mark. __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] The Reference Scanner and Jakarta Tomcat - Heap Profiling, Memory Leaks
Hi,
Come on people. Tomcat5 is built with MX4J because its license is now
OK (and I modified the NOTICE file that ships with tomcat5 accordingly).
If you want to recompile things to need to make sure your classpath is
setup accordingly: either figure it out from the tomcat build file or
nag Senor Baumgaertel to add instructions to his documents. It's just
like the HttpScanner thing you mentioned: he didn't document the import
statement for that class, but it's fairly obvious.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Joseph Shraibman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 12:19 AM
To: Tomcat Users List
Subject: Re: [ANN] The Reference Scanner and Jakarta Tomcat - Heap
Profiling, Memory Leaks
Jacob Kjome wrote:
At 11:47 PM 5/11/2004 -0400, you wrote:
Joerg Baumgaertel wrote:
Hi all,
because often requested,
I added a Jakarta-Tomcat-Howto to the 'jb2works.com' website.
You find the following documents
- How to scan a Java webapplication
http://jb2works.com/refscan/tomcat.html
- How to scan Jakarta-Tomcat full-space
http://jb2works.com/refscan/tomcatfull.html
I tried that, but when trying to run tomcat I got:
Due to new licensing guidelines mandated by the Apache Software
Foundation Board of Directors, a JMX implementation can no longer
be distributed with the Apache Tomcat binaries. As a result, you
must download a JMX 1.2 implementation (such as the Sun Reference
Implementation) and copy the JAR containing the API and
implementation of the JMX specification to:
${catalina.home}/bin/jmx.jar
...which confuses me, because jmx.jar is still where it always was.
Using the bootstrap.jar that came with tomcat works fine.
If you use the latest version of Tomcat5, you'll find that this is
not
an issue. Download Tomcat-5.0.24. The implementation of JMX that
said
version of Tomcat comes with is MX4J which is open source so there is
no
problem anymore.
Jake
I am using 5.0.24, and jmx.jar is there. Tomcat works if I use the
Bootstrap.class that comes with it, but if I recompile Bootstrap.class
per the instructions on http://jb2works.com/refscan/tomcatfull.html it
suddenly gives me that error message.
I can post the jar file if you think that will help.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] The Reference Scanner and Jakarta Tomcat - Heap Profiling, Memory Leaks
Quoting Joseph Shraibman [EMAIL PROTECTED]:
Jacob Kjome wrote:
At 11:47 PM 5/11/2004 -0400, you wrote:
Joerg Baumgaertel wrote:
Hi all,
because often requested,
I added a Jakarta-Tomcat-Howto to the 'jb2works.com' website.
You find the following documents
- How to scan a Java webapplication
http://jb2works.com/refscan/tomcat.html
- How to scan Jakarta-Tomcat full-space
http://jb2works.com/refscan/tomcatfull.html
I tried that, but when trying to run tomcat I got:
Due to new licensing guidelines mandated by the Apache Software
Foundation Board of Directors, a JMX implementation can no longer
be distributed with the Apache Tomcat binaries. As a result, you
must download a JMX 1.2 implementation (such as the Sun Reference
Implementation) and copy the JAR containing the API and
implementation of the JMX specification to:
${catalina.home}/bin/jmx.jar
...which confuses me, because jmx.jar is still where it always was.
Using the bootstrap.jar that came with tomcat works fine.
If you use the latest version of Tomcat5, you'll find that this is not
an issue. Download Tomcat-5.0.24. The implementation of JMX that said
version of Tomcat comes with is MX4J which is open source so there is no
problem anymore.
Jake
I am using 5.0.24, and jmx.jar is there. Tomcat works if I use the
Bootstrap.class that comes with it, but if I recompile Bootstrap.class
per the instructions on http://jb2works.com/refscan/tomcatfull.html it
suddenly gives me that error message.
I can post the jar file if you think that will help.
No, I can't help you with recompile questions. I just know that previous
versions of Tomcat required you to provide the JMX jar since they had been
shipping the Sun implementation, and probably in violation of the license. For
this reason, they removed jmx.jar, but they have added it back now that they use
the MX4J implementation. I can't remember if this affected Tomcat-5.0.19 or
alpha releases in between 5.0.19 and 5.0.24. All I can say is that, out of the
box, 5.0.24 should work just fine.
Jake
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] The Reference Scanner and Jakarta Tomcat - Heap Profiling, Memory Leaks
Joerg Baumgaertel wrote:
Hi all,
because often requested,
I added a Jakarta-Tomcat-Howto to the 'jb2works.com' website.
You find the following documents
- How to scan a Java webapplication
http://jb2works.com/refscan/tomcat.html
- How to scan Jakarta-Tomcat full-space
http://jb2works.com/refscan/tomcatfull.html
I tried that, but when trying to run tomcat I got:
Due to new licensing guidelines mandated by the Apache Software
Foundation Board of Directors, a JMX implementation can no longer
be distributed with the Apache Tomcat binaries. As a result, you
must download a JMX 1.2 implementation (such as the Sun Reference
Implementation) and copy the JAR containing the API and
implementation of the JMX specification to:
${catalina.home}/bin/jmx.jar
...which confuses me, because jmx.jar is still where it always was.
Using the bootstrap.jar that came with tomcat works fine.
BTW in your instructions you say to add:
HttpScanner.start( startupInstance );
... but what is really needed is:
com.jb2works.reference.HttpScanner.start( startupInstance ); // -- !!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] The Reference Scanner and Jakarta Tomcat - Heap Profiling, Memory Leaks
At 11:47 PM 5/11/2004 -0400, you wrote:
Joerg Baumgaertel wrote:
Hi all,
because often requested,
I added a Jakarta-Tomcat-Howto to the 'jb2works.com' website.
You find the following documents
- How to scan a Java webapplication
http://jb2works.com/refscan/tomcat.html
- How to scan Jakarta-Tomcat full-space
http://jb2works.com/refscan/tomcatfull.html
I tried that, but when trying to run tomcat I got:
Due to new licensing guidelines mandated by the Apache Software
Foundation Board of Directors, a JMX implementation can no longer
be distributed with the Apache Tomcat binaries. As a result, you
must download a JMX 1.2 implementation (such as the Sun Reference
Implementation) and copy the JAR containing the API and
implementation of the JMX specification to:
${catalina.home}/bin/jmx.jar
...which confuses me, because jmx.jar is still where it always was. Using
the bootstrap.jar that came with tomcat works fine.
If you use the latest version of Tomcat5, you'll find that this is not an
issue. Download Tomcat-5.0.24. The implementation of JMX that said
version of Tomcat comes with is MX4J which is open source so there is no
problem anymore.
Jake
BTW in your instructions you say to add:
HttpScanner.start( startupInstance );
... but what is really needed is:
com.jb2works.reference.HttpScanner.start( startupInstance ); // -- !!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] The Reference Scanner and Jakarta Tomcat - Heap Profiling, Memory Leaks
Jacob Kjome wrote:
At 11:47 PM 5/11/2004 -0400, you wrote:
Joerg Baumgaertel wrote:
Hi all,
because often requested,
I added a Jakarta-Tomcat-Howto to the 'jb2works.com' website.
You find the following documents
- How to scan a Java webapplication
http://jb2works.com/refscan/tomcat.html
- How to scan Jakarta-Tomcat full-space
http://jb2works.com/refscan/tomcatfull.html
I tried that, but when trying to run tomcat I got:
Due to new licensing guidelines mandated by the Apache Software
Foundation Board of Directors, a JMX implementation can no longer
be distributed with the Apache Tomcat binaries. As a result, you
must download a JMX 1.2 implementation (such as the Sun Reference
Implementation) and copy the JAR containing the API and
implementation of the JMX specification to:
${catalina.home}/bin/jmx.jar
...which confuses me, because jmx.jar is still where it always was.
Using the bootstrap.jar that came with tomcat works fine.
If you use the latest version of Tomcat5, you'll find that this is not
an issue. Download Tomcat-5.0.24. The implementation of JMX that said
version of Tomcat comes with is MX4J which is open source so there is no
problem anymore.
Jake
I am using 5.0.24, and jmx.jar is there. Tomcat works if I use the
Bootstrap.class that comes with it, but if I recompile Bootstrap.class
per the instructions on http://jb2works.com/refscan/tomcatfull.html it
suddenly gives me that error message.
I can post the jar file if you think that will help.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] The Reference Scanner and Jakarta Tomcat - Heap Profiling, Memory Leaks
Hi all, because often requested, I added a Jakarta-Tomcat-Howto to the 'jb2works.com' website. You find the following documents - How to scan a Java webapplication http://jb2works.com/refscan/tomcat.html - How to scan Jakarta-Tomcat full-space http://jb2works.com/refscan/tomcatfull.html About the Reference Scanner itself, [From Announcement in c.l.j.p] The Reference Scanner Use this memory profiler .jar to inspect your running Java application from your web browser. Get heap snapshots and snapshot diffs. Find memory leaks. Analyze the reference graph for objects kept in memory. Do simulate Cuts for found memory leaks. Your application runs at normal speed. Does not require the JVM debug mode. Low memory consumption. The software is free downloadable. Only 810k .jar file. usage http://jb2works.com/refscan/usage.html screenshots http://jb2works.com/refscan/usage.html#heapprofile feature matrix http://jb2works.com/refscan/matrix.html download http://jb2works.com/refscan/status.html#status faq http://jb2works.com/refscan/faq.html junit http://jb2works.com/refscan/junit.html I would like to see you enjoying this software! Best regards, Joerg Baumgaertel, jb2works.com 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best App for Finding Memory leaks in WebApps running on Tomcat
Hello All, Just wondering what you think is the best App for Finding Memory leaks in WebApps running on Tomcat Is Jprobe the consensus? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best App for Finding Memory leaks in WebApps running on Tomcat
Hi, Just wondering what you think is the best App for Finding Memory leaks in WebApps running on Tomcat Is Jprobe the consensus? Far from it. OptimizeIt and JProbe are probably the leaders among the $$$ options with equal popularity. I like OptimizeIt better but both are good. There are free alternatives as well, see http://www.manageability.org/blog/stuff/open-source-profilers-for-java Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best App for Finding Memory leaks in WebApps running on Tomca t
Thanks Yoav, So if price was not a consideration, which would you go with? -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:51 PM To: Tomcat Users List Subject: RE: Best App for Finding Memory leaks in WebApps running on Tomcat Hi, Just wondering what you think is the best App for Finding Memory leaks in WebApps running on Tomcat Is Jprobe the consensus? Far from it. OptimizeIt and JProbe are probably the leaders among the $$$ options with equal popularity. I like OptimizeIt better but both are good. There are free alternatives as well, see http://www.manageability.org/blog/stuff/open-source-profilers-for-java Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best App for Finding Memory leaks in WebApps running on Tomcat
Hi, So if price was not a consideration, which would you go with? OptimizeIt. But my view is skewed in that I've been using OptimizeIt for years and have naturally become adept at it. I don't think OptimizeIt and JProbe are much different from each other, both are excellent. I think the free ones in the link I sent before by and large have a LONG way to go. I've been waiting for a full-featured and fast open-source profiler for years ;( I think perhaps with the new low-overhead JVMPI/DI/whatever interfaces in JDK 1.5, we'll finally see a nice open-source profiler. crossing fingers / Yoav Shapira -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:51 PM To: Tomcat Users List Subject: RE: Best App for Finding Memory leaks in WebApps running on Tomcat Hi, Just wondering what you think is the best App for Finding Memory leaks in WebApps running on Tomcat Is Jprobe the consensus? Far from it. OptimizeIt and JProbe are probably the leaders among the $$$ options with equal popularity. I like OptimizeIt better but both are good. There are free alternatives as well, see http://www.manageability.org/blog/stuff/open-source-profilers-for-java Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best App for Finding Memory leaks in WebApps running on Tomca t
I went with Jprofiler, from ej-technologies.. It is very easy to configure and use. -reynir Robert Priest wrote: Thanks Yoav, So if price was not a consideration, which would you go with? -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:51 PM To: Tomcat Users List Subject: RE: Best App for Finding Memory leaks in WebApps running on Tomcat Hi, Just wondering what you think is the best App for Finding Memory leaks in WebApps running on Tomcat Is Jprobe the consensus? Far from it. OptimizeIt and JProbe are probably the leaders among the $$$ options with equal popularity. I like OptimizeIt better but both are good. There are free alternatives as well, see http://www.manageability.org/blog/stuff/open-source-profilers-for-java Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Memory Leaks
Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Howdy, Enable verbose GC (see Java VM Options for how to do this). Yoav Shapira Millennium ChemInformatics -Original Message- From: Christian Witucki [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 9:00 AM To: [EMAIL PROTECTED] Subject: Memory Leaks Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e- mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
I've been looking at this this week and have resolved that we need to buy a JVM Profiler, prob. JProfiler. -Original Message- From: Christian Witucki [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:00 To: [EMAIL PROTECTED] Subject: Memory Leaks Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
I have a problem with memory leak. You have see my message BIG PROBLEM // LINUX TOMCAT SSL ? -Message d'origine- De : Christian Witucki [mailto:[EMAIL PROTECTED] Envoy : mercredi 14 janvier 2004 15:00 : [EMAIL PROTECTED] Objet : Memory Leaks Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
My understanding is that the GC runs on a low-priority thread, so you never get to tell it when to run. The operating system and JVM deal with it. I also recall reading that memory is returned to the JVM, but not released back to the OS. So if you're watching Memory Usage in the Windows Task Manager and not seeing it go down, that might explain why. - MOD --- Christian Witucki [EMAIL PROTECTED] wrote: Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Hi There, You can invoke the garbage collector by using the System.gc() method. The memory is never returned to OS but the JVM keeps it in a pool used for object creation, it would make no sense in releasing this back to the OS as it will probably need to use it at some point or another. In more recent JVM's (1.4 onwards) the garbage collector has been threaded to improve performance and penalties as until then the cost of a collection was relatively expensive. For more information read the documentation at www.java.sun.com Hope this helps Pete -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:07 To: Tomcat Users List Subject: Re: Memory Leaks My understanding is that the GC runs on a low-priority thread, so you never get to tell it when to run. The operating system and JVM deal with it. I also recall reading that memory is returned to the JVM, but not released back to the OS. So if you're watching Memory Usage in the Windows Task Manager and not seeing it go down, that might explain why. - MOD --- Christian Witucki [EMAIL PROTECTED] wrote: Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Howdy, Just one correction: You can invoke the garbage collector by using the System.gc() method. This is a common misconception: System.gc() is merely a suggestion to the VM to run collection. The VM is not obliged to run it then, i.e. this is not a hard directive. It should never be relied upon. With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. Yoav Shapira The memory is never returned to OS but the JVM keeps it in a pool used for object creation, it would make no sense in releasing this back to the OS as it will probably need to use it at some point or another. In more recent JVM's (1.4 onwards) the garbage collector has been threaded to improve performance and penalties as until then the cost of a collection was relatively expensive. For more information read the documentation at www.java.sun.com Hope this helps Pete -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:07 To: Tomcat Users List Subject: Re: Memory Leaks My understanding is that the GC runs on a low-priority thread, so you never get to tell it when to run. The operating system and JVM deal with it. I also recall reading that memory is returned to the JVM, but not released back to the OS. So if you're watching Memory Usage in the Windows Task Manager and not seeing it go down, that might explain why. - MOD --- Christian Witucki [EMAIL PROTECTED] wrote: Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
Hi! Shapira, Yoav wrote: This is a common misconception: System.gc() is merely a suggestion to the VM to run collection. The VM is not obliged to run it then, i.e. this is not a hard directive. It should never be relied upon. With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. Also, calling System.gc() is unnecessary in allmost all cases it is used. The VM does a far better job in determining when the gc should run than most programmers could. Only if you know your way around in the internals of the VM and you know that it will not run a gc cycle that would beneficial, you can call System.gc() to politely ask the VM to do so. Still no garantees, though. In any case, although a call to System.cg() will most likely no hurt your performance, you should never ever rely on it. Phil -- And on the seventh day, He exited from append mode. (Book of create(2), line 255) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
In general true and that's what the spec says, but we had once following experience with a version of a jvm (can't recall which): The vm was not able to perform the gc if an out of memory occured, even if enough free objects where there to free quite some memory. (Obviously the gc didn't start at a treshhold but only when the memory was full, and couldn't get the memory it needed to perform the task) The problem vanished when we started to call gc() on a regular base. the call to gc() had some effect. (Runtime.freeMemory() grew after each call to gc()) This indicated, that (with that specific vm) the call to gc() did something. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 3:43 PM To: Tomcat Users List Subject: RE: Memory Leaks This is a common misconception: System.gc() is merely a suggestion to the VM to run collection. The VM is not obliged to run it then, i.e. this is not a hard directive. It should never be relied upon. With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
Yoav, With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. What is this parameter? I've never seen it before... -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Howdy, With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. What is this parameter? I've never seen it before... -chris -XX:+DisableExplicitGC is the parameter, which I believe has been available since JDK 1.4.0. Yoav Shapria This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
Yoav, With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. What is this parameter? I've never seen it before... -XX:+DisableExplicitGC is the parameter, which I believe has been available since JDK 1.4.0. Wow, I didn't know that -XX parameters existed. Where can I get more information on these, if you don't mind? Thanks, -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
http://java.sun.com/docs/hotspot/VMOptions.html -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 4:17 PM To: Tomcat Users List Subject: Re: Memory Leaks Wow, I didn't know that -XX parameters existed. Where can I get more information on these, if you don't mind? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Vedr.: Re: Memory Leaks
Hey Chris, sorry for interrupting but if you into optimizing your JVM setting as well as explorings its options I would recommend: - http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/ - http://java.sun.com/docs/hotspot/gc1.4.2/ Perhaps some of the more savvy developers can give more directions. As always remember the best tests are those carried out by yourself profiling you applications - if I didnt say SOMEONE else would have... ;-) Christopher Schultz [EMAIL PROTECTED] 14-01-2004 16:17 Besvar venligst til Tomcat Users List Til:Tomcat Users List [EMAIL PROTECTED] cc: Vedr.: Re: Memory Leaks Yoav, With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. What is this parameter? I've never seen it before... -XX:+DisableExplicitGC is the parameter, which I believe has been available since JDK 1.4.0. Wow, I didn't know that -XX parameters existed. Where can I get more information on these, if you don't mind? Thanks, -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=Arial___ Vi goer opmaerksom paa, at denne e-mail kan indeholde fortrolig information. Hvis du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen ved at bruge svar-funktionen. Samtidig beder vi dig slette e-mailen i dit system uden at videresende eller kopiere den. Selv om e-mailen og ethvert vedhaeftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan paavirke computeren eller it-systemet, hvori den modtages og laeses, aabnes den paa modtagerens eget ansvar. Vi paatager os ikke noget ansvar for tab og skade, som er opstaaet i forbindelse med at modtage og bruge e-mailen. ___ Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message. /FONT
Re: Vedr.: Re: Memory Leaks
Thomas, sorry for interrupting but if you into optimizing your JVM setting as well as explorings its options I would recommend: Perhaps some of the more savvy developers can give more directions. Thanks for the pointers. Actually, I'm not having any performance problems at the moment :) As always remember the best tests are those carried out by yourself profiling you applications - if I didnt say SOMEONE else would have... I've been running OptimizeIt and Tomcat together and quite a while. You don't need to convince me! -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : memory-leaks in servlets, tool for tracing ?
When does a class reload occur ? When u update a JSP ? When u update a class ? When u update a lib ? When u do reload in the manager webapps ? = yes :) Anything else ? -Message d'origine- De : Christopher Schultz [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 23:31 À : Tomcat Users List Objet : Re: RE : memory-leaks in servlets, tool for tracing ? Laurent, What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? I don't believe that the VM ever releases resources taken up by Class objects (I think this includes static resources for a class). There used to be a VM option, -noclassgc, that was often used so that instance-less Classes wouldn't get GC'd. Almost everyone who ran Java apps turned that option on. I'm not even sure if that option is still available. They may have simply eliminated the GC'ing of Class objects altogether. I know that in my stock tc 4.1.27 on Sun's 1.4.2 VM, that after a re-load, all the old Class objects stick around. It's quite disconcerting because the heap grows by around 600 classes every time a context-reload occurs. The solution, of course, is not to enable context-reloading on production :) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : memory-leaks in servlets, tool for tracing ?
Howdy, context-reload occurs. The solution, of course, is not to enable context-reloading on production :) This is very good advice. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : RE : memory-leaks in servlets, tool for tracing ?
Laurent, When does a class reload occur ? I was talking about a context re-load, which dumps everything in the context and re-starts it in a new ClassLoader. When u update a JSP ? Yes, the class gets re-loaded, but not the whole context. This is much less of a problem. When u update a class ? Sometimes is depende on the class you update. If you update a servlet that's mapped in web.xml, then Tomcat will definately re-load the context. Sometimes it seems like if I update a bean class that Tomcat doesn't re-load. I don't know it's checking technique. When u update a lib ? I don't think it re-loads the context for a lib update. When u do reload in the manager webapps ? = yes :) Of course! It will also re-load if web.xml changes, and I've seen it re-load sometimes if anything directly in the WEB-INF directory changes (i.e. I have struts-config.xml in my current application, and if I change that, sometimes it reloads). -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: memory-leaks in servlets, tool for tracing ?
Christopher, thanks for your comprehensive response ! See more comments down ... - Original Message - From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 3:29 PM Subject: Re: memory-leaks in servlets, tool for tracing ? Grisi, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Have you looked at the memory over a long time, including several large GCs? I've had to do this in the past, and it's no fun without a profiler. No, it isn't indeed. I've been checking LINUX' 'top' over a period of time. A mem-hole is apparent. Unfortunately our app makes use of a (self-developed) JNI-Module (C) which makes it even more difficult because the C-code also runs in the Java-context. Unfortunately, profiling tools can get expensive. Anyone know of any decent OSS ones out there? 'JProbe' and 'OptimizeIt!' are really no bargains ! When I've done this sans profiler in the past, I did two things: 1. Turn on verbose GC for the VM (dumps GC stats to stdout) 2. Write a program to parse the GC lines and graph them over time We got a curve that looked like this: - max memory /\ / used memory-/\ / \___/ /\ / \___/ / \___/ --/ ^ OutOfMemoryError This indicated that we were really screwing up somewhere. Had the curve looked like this, we would be happy: - max memory /\ /\ /\ / \ / \ / \ /\ /\ /\ / \_/ \_/ \ _/ ... or even with high-frequency perturbations in there (usually from minor GCs happening periodically). It often helps to set the initial heap size and the maximum heap size to the same value (usually something like 256MB, 512MB, or 1024MB). Just remember that the higher it is, the longer you'll have to wait for a full GC. GCs don't always free everything they can. If they did, they'd take forever. It's only when the VM gets near its maximum heap size that the GC panics and goes on a collection rampage. If you ever get an OutOfMemoryError, go and get a thread-dump. On UNIX, you can sent the VM a STOP signal using kill or by pressing CTRL-\ if the VM is running in a terminal. Good idea, I also achieved this by narrowing available mem on the machine until java gave up quitting with an 'out-of-mem' err. The problem is that the dump written only contains the hex-adresses of the modules being involved. No possibilty to trace those adressesdown to the functions or even modules involved. Even more difficult: the root cause given by this dump is not the function(s)/method(s) causing the memory problems. You'll get lots of good information including the number of threads and where they are. You might find that there are threads there that you thought had terminated long ago. Old active threads are always a source of tied-up memory. Does anybody's got experience with a profiling toolkit which she/he can suggest ? There is a tool provided by SUN itself called 'HAT' (HeapAnalyzingTool) http://java.sun.com/people/billf/heap/ but this seems to be only applicable to java programs, not servlets. With Tomcat there were errors. May be in different cases this would help. I have some experience with Borland's OptimizeIt, and I've even recently installed it on Linux and run Tomcat 4.1 through it. I was able to determine something about the VM and Tomcat that might help you. I thought I had a memory leak, too. In our case it was helpful to operate java with the -Xincgc option that causes the GC to collect smaller amounts of mem; but does this more often. It gives a more accurate impression in the current memory status. What we did is the following: - separate the JNI-module and write a little main()-frame around it to run it alone. - compile this with the 'dmalloc'-library to identify mem not being free'd there. - running the Servlet in one scenario (without JNI) and examine the few methods being touched. - rewrite java-code being in question. - test it on mem-behavior. - iterate with the next scenario etc. Could be more satisfying, this kind of work, but it should be straight-forward. It turns out that when you recompile your servlets and Tomcat does an auto-reload (I have it configured that way), a new ClassLoader gets installed to hold the classes loaded for the new context. However, the classes loaded from the old context stick around because the JVM doesn't want to discard java.lang.Class objects in case they're useful in the future. This increases the number of java.lang.Class objects by about 600 every time I recompiled. After many compile-deploy-reload cycles, my VM was hogging all my memory and lots
Re: memory-leaks in servlets, tool for tracing ?
Grisi, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Have you looked at the memory over a long time, including several large GCs? I've had to do this in the past, and it's no fun without a profiler. No, it isn't indeed. I've been checking LINUX' 'top' over a period of time. A mem-hole is apparent. Unfortunately our app makes use of a (self-developed) JNI-Module (C) which makes it even more difficult because the C-code also runs in the Java-context. Ooh, JNI is always a wild-card. I wrote some JNI code that we were using within a servlet container as well. I tested the hell out of it, especially with threaded use (that's very important). I could only get it to fail when it had trouble writing to files at very high thread rates (I made each thread write to files on a floppy disk, which would run out of space and cause an I/O error). I'd highly recommend testing your native library separately from the use of JNI and the servlet. Try setting up a test harness for the native code to see if there are easier memory leaks to find. Adding JNI and the VM on top of all that it tough. Some profiles claim to allow you to watch native code as well as Java code (which sounds really cool!), but again they are expensive. You can use gdb and clever use of tests that are likely to break your code without getting Java involved. Unfortunately, profiling tools can get expensive. Anyone know of any decent OSS ones out there? I don't. Anyone have any ideas? Some intern at my old company wrote one from scratch, apparently, so I'm guessing they aren't TOO hard. He used the JVMDP or whatever, which is a debugging protocol that you use to attach to a running VM process. 'JProbe' and 'OptimizeIt!' are really no bargains ! Well, that depends on how much money you are going to spend to find the problem otherwise. How much do you (and your team) cost per hour to your employer? If it's going to take you a week (40 hours * x team members), then how does that compare to the cost of an OptimizeIt license...? The problem is that the [thread] dump written only contains the hex-adresses of the modules being involved. No possibilty to trace those adressesdown to the functions or even modules involved. Yeah, that's a problem. You'd have to do a lot of investigation to figure out what's actually being executed. Even more difficult: the root cause given by this dump is not the function(s)/method(s) causing the memory problems. Well, once you get an OutOfMemoryException, you pretty much can't trust anything the VM says after that. What you're seeing is just a guide; they might be total lies. :) There is a tool provided by SUN itself called 'HAT' (HeapAnalyzingTool) http://java.sun.com/people/billf/heap/ but this seems to be only applicable to java programs, not servlets. With Tomcat there were errors. May be in different cases this would help. Well, Tomcat is a Java program, so you should be able to use it, right? It's just a matter of figuring out how to hook it into your startup process. I hacked through the OptimizeIt instructions and created an ant target to start my Tomcat instance running inside of OptimizeIt. Very sexy. In our case it was helpful to operate java with the -Xincgc option that causes the GC to collect smaller amounts of mem; but does this more often. It gives a more accurate impression in the current memory status. What we did is the following: - separate the JNI-module and write a little main()-frame around it to run it alone. - compile this with the 'dmalloc'-library to identify mem not being free'd there. - running the Servlet in one scenario (without JNI) and examine the few methods being touched. - rewrite java-code being in question. - test it on mem-behavior. - iterate with the next scenario etc. Could be more satisfying, this kind of work, but it should be straight-forward. Well, that's the approach I'd take without a profiler. Good luck. Let us know what you find. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Howdy, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing This basic idea that memory usage should be constant over time is very common and usually wrong. The JVM will use as much memory as it needs without GC'ing until it has to. So if you give it 1GB for an app that needs 10MB, and keep that app running for long, you'd see memory usage increasing and increasing until GC is fired. Even then, the heap will stay where it was, only the %free will be much higher. The better solution here is not to give your app so much memory, make GC run more often, and track the %free instead of just total process image memory via the top command. You need to find it if there are memory leaks, of if the memory increase is legitimate, e.g. due to high usage. I'd highly recommend testing your native library separately from the use That's a very good suggestion. Unfortunately, profiling tools can get expensive. Anyone know of any decent OSS ones out there? The question comes up every couple of months on this list, search the archives. Personally, I think OptimizeIt is worth its price without a doubt. I don't. Anyone have any ideas? Some intern at my old company wrote one from scratch, apparently, so I'm guessing they aren't TOO hard. He used the JVMDP or whatever, which is a debugging protocol that you use to attach to a running VM process. It's easy to write bad profilers, each EXTREMELY difficult to write profilers with low overhead. It's the JVMPI (Java Virtual Machine Profiling Interface) that you must implement. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Yoav, You make a great point about how the app should stabilize it's memory usage over time. However, I've got a question about memory usage when I stop (via Tomcat manager) and reload a webapp via a WAR file. If I understand your point, and I'm close to the max heap size, shouldn't GC free up the memory from the old webapp? In my case, GC happens more frequently, but doesn't do a great job (not even close to freeing up the memory footprint of my webapp). Eventually, I run into out of memory problems. Shouldn't a reload of a webapp cause a relase of the resources from the old webapp? -Anthony Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Howdy, You make a great point about how the app should stabilize it's memory usage over time. However, I've got a question about memory usage when I stop (via Tomcat manager) and reload a webapp via a WAR file. If I understand your point, and I'm close to the max heap size, shouldn't GC free up the memory from the old webapp? In my case, GC happens more frequently, but doesn't do a great job (not even close to freeing up the memory footprint of my webapp). Eventually, I run into out of memory problems. Shouldn't a reload of a webapp cause a relase of the resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : memory-leaks in servlets, tool for tracing ?
What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? -Message d'origine- De : Shapira, Yoav [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 15:57 À : Tomcat Users List Objet : RE: memory-leaks in servlets, tool for tracing ? Howdy, You make a great point about how the app should stabilize it's memory usage over time. However, I've got a question about memory usage when I stop (via Tomcat manager) and reload a webapp via a WAR file. If I understand your point, and I'm close to the max heap size, shouldn't GC free up the memory from the old webapp? In my case, GC happens more frequently, but doesn't do a great job (not even close to freeing up the memory footprint of my webapp). Eventually, I run into out of memory problems. Shouldn't a reload of a webapp cause a relase of the resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : memory-leaks in servlets, tool for tracing ?
It would be good if some of you writes an kind of howTo that shows : - a webapp with a memory leak. - the use of a profiler program ( with screenshots ) to detect the memory leak. -Message d'origine- De : Laurent Michenaud Envoyé : mercredi 5 novembre 2003 16:56 À : Tomcat Users List Objet : RE : memory-leaks in servlets, tool for tracing ? What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? -Message d'origine- De : Shapira, Yoav [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 15:57 À : Tomcat Users List Objet : RE: memory-leaks in servlets, tool for tracing ? Howdy, You make a great point about how the app should stabilize it's memory usage over time. However, I've got a question about memory usage when I stop (via Tomcat manager) and reload a webapp via a WAR file. If I understand your point, and I'm close to the max heap size, shouldn't GC free up the memory from the old webapp? In my case, GC happens more frequently, but doesn't do a great job (not even close to freeing up the memory footprint of my webapp). Eventually, I run into out of memory problems. Shouldn't a reload of a webapp cause a relase of the resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : RE : memory-leaks in servlets, tool for tracing ?
Howdy, That'd be good, and I think there are some efforts in this area. (Is Peter Lin's apache performance book available for online purchase?) You can google for them. Another one with a specific app is a good idea, but requires a lot of time ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Laurent Michenaud [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 10:59 AM To: Tomcat Users List Subject: RE : RE : memory-leaks in servlets, tool for tracing ? It would be good if some of you writes an kind of howTo that shows : - a webapp with a memory leak. - the use of a profiler program ( with screenshots ) to detect the memory leak. -Message d'origine- De : Laurent Michenaud Envoyé : mercredi 5 novembre 2003 16:56 À : Tomcat Users List Objet : RE : memory-leaks in servlets, tool for tracing ? What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? -Message d'origine- De : Shapira, Yoav [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 15:57 À : Tomcat Users List Objet : RE: memory-leaks in servlets, tool for tracing ? Howdy, You make a great point about how the app should stabilize it's memory usage over time. However, I've got a question about memory usage when I stop (via Tomcat manager) and reload a webapp via a WAR file. If I understand your point, and I'm close to the max heap size, shouldn't GC free up the memory from the old webapp? In my case, GC happens more frequently, but doesn't do a great job (not even close to freeing up the memory footprint of my webapp). Eventually, I run into out of memory problems. Shouldn't a reload of a webapp cause a relase of the resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : memory-leaks in servlets, tool for tracing ?
Laurent, What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? I don't believe that the VM ever releases resources taken up by Class objects (I think this includes static resources for a class). There used to be a VM option, -noclassgc, that was often used so that instance-less Classes wouldn't get GC'd. Almost everyone who ran Java apps turned that option on. I'm not even sure if that option is still available. They may have simply eliminated the GC'ing of Class objects altogether. I know that in my stock tc 4.1.27 on Sun's 1.4.2 VM, that after a re-load, all the old Class objects stick around. It's quite disconcerting because the heap grows by around 600 classes every time a context-reload occurs. The solution, of course, is not to enable context-reloading on production :) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
memory-leaks in servlets, tool for tracing ?
hi everybody, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Does anybody's got experience with a profiling toolkit which she/he can suggest ? grisi
RE: memory-leaks in servlets, tool for tracing ?
Howdy, I like OptimizeIt's heap snapshots. Yoav Shapira Millennium ChemInformatics -Original Message- From: Dirk Griesbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 4:03 AM To: Tomcat Users List Subject: memory-leaks in servlets, tool for tracing ? hi everybody, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Does anybody's got experience with a profiling toolkit which she/he can suggest ? grisi This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: memory-leaks in servlets, tool for tracing ?
Grisi, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Have you looked at the memory over a long time, including several large GCs? I've had to do this in the past, and it's no fun without a profiler. Unfortunately, profiling tools can get expensive. Anyone know of any decent OSS ones out there? When I've done this sans profiler in the past, I did two things: 1. Turn on verbose GC for the VM (dumps GC stats to stdout) 2. Write a program to parse the GC lines and graph them over time We got a curve that looked like this: - max memory /\ / used memory-/\ / \___/ /\ / \___/ / \___/ --/ ^ OutOfMemoryError This indicated that we were really screwing up somewhere. Had the curve looked like this, we would be happy: - max memory /\ /\ /\ / \ / \ / \ /\ /\ /\ / \_/ \_/ \ _/ ... or even with high-frequency perturbations in there (usually from minor GCs happening periodically). It often helps to set the initial heap size and the maximum heap size to the same value (usually something like 256MB, 512MB, or 1024MB). Just remember that the higher it is, the longer you'll have to wait for a full GC. GCs don't always free everything they can. If they did, they'd take forever. It's only when the VM gets near its maximum heap size that the GC panics and goes on a collection rampage. If you ever get an OutOfMemoryError, go and get a thread-dump. On UNIX, you can sent the VM a STOP signal using kill or by pressing CTRL-\ if the VM is running in a terminal. You'll get lots of good information including the number of threads and where they are. You might find that there are threads there that you thought had terminated long ago. Old active threads are always a source of tied-up memory. Does anybody's got experience with a profiling toolkit which she/he can suggest ? I have some experience with Borland's OptimizeIt, and I've even recently installed it on Linux and run Tomcat 4.1 through it. I was able to determine something about the VM and Tomcat that might help you. I thought I had a memory leak, too. It turns out that when you recompile your servlets and Tomcat does an auto-reload (I have it configured that way), a new ClassLoader gets installed to hold the classes loaded for the new context. However, the classes loaded from the old context stick around because the JVM doesn't want to discard java.lang.Class objects in case they're useful in the future. This increases the number of java.lang.Class objects by about 600 every time I recompiled. After many compile-deploy-reload cycles, my VM was hogging all my memory and lots of CPU. Perhaps this is your problem, too? -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
may be a little off topic, but - check to see if you are logging any 404 messages on the tomcat side - i have found that memory and cpu idle time seem to dissappear with every 404 request passed over to tomcat from apache Sai. On Fri, 5 Sep 2003 12:09:52 -0500, Mike Curwen wrote After about 15 emails, I'm gonna go back to the first: I seemed to have read that java/tomcat isn't supposed to have memory leaks, AND So where do I start looking for the problem? If I forget to close Statements would that cause the problem? So first of all, Java has built-in memory management and garbage collection, so comparing against a language like C++, it's MUCH harder to cause a memory leak in a Java program, *but not impossible*. And up to now we're focusing on JDBC. Connection pools and whether or not your driver strictly adheres to the JDBC standard are certainly one source of memory leaks. But they're not the only ones possible. What sorts of other activities are going on in your application? Do you have other 3rd party libraries? Libraries you've written yourself? Have these been profiled and exercised to ensure they are not the ones leaking? -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 9:37 AM To: Tomcat Users List Subject: Re: Memory leaks? I'm most certain the connections are closed but there may be a few dangling statements. I'm using mysql jdbc. Not using pools since I never could get it working. Making direct requests. Still getting a out of memory hit every couple of days so I have to shutdown the server and start it up again. THnak,s Jim. Shapira, Yoav wrote: Howdy, You don't have to close a result set if you're closing the statement right away and the result set is the only one associated with the statement... And in no case can closing the result set explicitly hurt performance. Yoav Shapira Millennium ChemInformatics -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 10:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/s ql/Statement.html#close( ) (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Open WebMail Project (http://openwebmail.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
But depending on the DB, it can cause problems from the DB with too many open ResultSets... I had an issue with performance testing where everything but ResultSets were being closed and the Oracle DB started throwing errors after about 500 queries. Better safe than sorry. Well, from what I know, in general (not Oracle specific). If you open a connection within some scope (Servlet, JSP, any other class), then create a statement and finally a result set, shouldn't deleting the most upper scope cause all these lower levels be closed and garbage collected? With Servlets and JSP, of course, you have no control whatsoever as to when they will be put out of service. But suppose you are tidy and do a close on the connection - shouldn't that clean-up the underlying Statement(s) and ResultSet(s)? Even with connection pooling, this should work. Nix.
Re: Memory leaks?
The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. When garbage collection runs is a whole different story. But its just good coding to close your ResultSet, Statements as soon as your done with them. -Tim Nikola Milutinovic wrote: But depending on the DB, it can cause problems from the DB with too many open ResultSets... I had an issue with performance testing where everything but ResultSets were being closed and the Oracle DB started throwing errors after about 500 queries. Better safe than sorry. Well, from what I know, in general (not Oracle specific). If you open a connection within some scope (Servlet, JSP, any other class), then create a statement and finally a result set, shouldn't deleting the most upper scope cause all these lower levels be closed and garbage collected? With Servlets and JSP, of course, you have no control whatsoever as to when they will be put out of service. But suppose you are tidy and do a close on the connection - shouldn't that clean-up the underlying Statement(s) and ResultSet(s)? Even with connection pooling, this should work. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Memory leaks?
As far as I know the Oracle JDBC driver does not follow the specificiation. You should close your all objects in the following order: 1) ResultSet 2) Statement 3) Connection -Ursprüngliche Nachricht- Von: Tim Funk [mailto:[EMAIL PROTECTED] Gesendet am: Freitag, 5. September 2003 13:02 An: Tomcat Users List Betreff: Re: Memory leaks? The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. When garbage collection runs is a whole different story. But its just good coding to close your ResultSet, Statements as soon as your done with them. -Tim Nikola Milutinovic wrote: But depending on the DB, it can cause problems from the DB with too many open ResultSets... I had an issue with performance testing where everything but ResultSets were being closed and the Oracle DB started throwing errors after about 500 queries. Better safe than sorry. Well, from what I know, in general (not Oracle specific). If you open a connection within some scope (Servlet, JSP, any other class), then create a statement and finally a result set, shouldn't deleting the most upper scope cause all these lower levels be closed and garbage collected? With Servlets and JSP, of course, you have no control whatsoever as to when they will be put out of service. But suppose you are tidy and do a close on the connection - shouldn't that clean-up the underlying Statement(s) and ResultSet(s)? Even with connection pooling, this should work. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
Tim Funk wrote: The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. So, that means that if you have a pool of ten connections, and you use each of those ten connections ten times with 2 ResultSets, you have 200 ResultSets sitting in memory, assuming you don't close them yourself? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
It depends. If your webapp calls connection.close(), then the result sets *should* be closed. But that is based one of the following assumptions: - Your connection is the actual db connection and the driver is JDBC compliant - The connection is a facade to the actual connection for the sake of using a database connection pool. And the facade is smart enough to close all dependent assets on that connection for you. I *try* to make my programmers only have one statement and result set open at a time per connection. If a second statement or result set needs opened, they should either close the existing resources or open another connection. They must always close ANYTHING they open. -Tim John Turner wrote: Tim Funk wrote: The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. So, that means that if you have a pool of ten connections, and you use each of those ten connections ten times with 2 ResultSets, you have 200 ResultSets sitting in memory, assuming you don't close them yourself? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
It's simple good practice to close objects that have close methods when you
no longer need them (as you do with stream objects, for example).
The spec says that ResultSet objects are closed when their Statement objects
are closed and that Statement objects are closed when their Connection
objects are closed. I personally like to keep hold of a Connection object
for the lifetime of my application (or until it fails), because connecting
to a database is an expensive operation. Also, if you use Connection
pooling, Connection objects can be kept open for as long as your application
server or whatever is running, so that unclosed Statements with their open
ResultSets simply sit around hogging resources (and some of the resources
that they hog, such as database cursors, are not lightweight).
This is what I do for JDBC calls:
// Assume a connection has been made
Connection conn...;
PreparedStatement ps = null;
ResultSet rs = null;
try {
// Create a PreparedStatement and use it to open a ResultSet
...
// Clean up
rs.close();
} catch (SQLException e) {
// Do something with the error
} finally {
try {
if (null != ps) {
ps.close();
} catch (SQLException e) {}
}
This guarantees that the objects are always closed (assuming, of course,
that the close() operations succeed). The rs.close() is, in theory,
unnecessary as the ps.close() call is supposed to close it implicitly, but
my background is in C and I always tried to free anything that I'd malloced.
It's a habit that's stuck.
In short, ALWAYS CLOSE YOUR STATEMENT OBJECTS.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
I'm most certain the connections are closed but there may be a few dangling statements. I'm using mysql jdbc. Not using pools since I never could get it working. Making direct requests. Still getting a out of memory hit every couple of days so I have to shutdown the server and start it up again. THnak,s Jim. Shapira, Yoav wrote: Howdy, You don't have to close a result set if you're closing the statement right away and the result set is the only one associated with the statement... And in no case can closing the result set explicitly hurt performance. Yoav Shapira Millennium ChemInformatics -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 10:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
After about 15 emails, I'm gonna go back to the first: I seemed to have read that java/tomcat isn't supposed to have memory leaks, AND So where do I start looking for the problem? If I forget to close Statements would that cause the problem? So first of all, Java has built-in memory management and garbage collection, so comparing against a language like C++, it's MUCH harder to cause a memory leak in a Java program, *but not impossible*. And up to now we're focusing on JDBC. Connection pools and whether or not your driver strictly adheres to the JDBC standard are certainly one source of memory leaks. But they're not the only ones possible. What sorts of other activities are going on in your application? Do you have other 3rd party libraries? Libraries you've written yourself? Have these been profiled and exercised to ensure they are not the ones leaking? -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 9:37 AM To: Tomcat Users List Subject: Re: Memory leaks? I'm most certain the connections are closed but there may be a few dangling statements. I'm using mysql jdbc. Not using pools since I never could get it working. Making direct requests. Still getting a out of memory hit every couple of days so I have to shutdown the server and start it up again. THnak,s Jim. Shapira, Yoav wrote: Howdy, You don't have to close a result set if you're closing the statement right away and the result set is the only one associated with the statement... And in no case can closing the result set explicitly hurt performance. Yoav Shapira Millennium ChemInformatics -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 10:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/s ql/Statement.html#close( ) (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
I have no home grown libs, but I do have a lib for the Split function and the gnu-regex lib. Now that split is available in 1.4 I could convert to it and see if that helps. I have no idea how to profile and exercise a library, so I'd have to answer no. Thanks, Jim. Mike Curwen wrote: After about 15 emails, I'm gonna go back to the first: I seemed to have read that java/tomcat isn't supposed to have memory leaks, AND So where do I start looking for the problem? If I forget to close Statements would that cause the problem? So first of all, Java has built-in memory management and garbage collection, so comparing against a language like C++, it's MUCH harder to cause a memory leak in a Java program, *but not impossible*. And up to now we're focusing on JDBC. Connection pools and whether or not your driver strictly adheres to the JDBC standard are certainly one source of memory leaks. But they're not the only ones possible. What sorts of other activities are going on in your application? Do you have other 3rd party libraries? Libraries you've written yourself? Have these been profiled and exercised to ensure they are not the ones leaking? -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 9:37 AM To: Tomcat Users List Subject: Re: Memory leaks? I'm most certain the connections are closed but there may be a few dangling statements. I'm using mysql jdbc. Not using pools since I never could get it working. Making direct requests. Still getting a out of memory hit every couple of days so I have to shutdown the server and start it up again. THnak,s Jim. Shapira, Yoav wrote: Howdy, You don't have to close a result set if you're closing the statement right away and the result set is the only one associated with the statement... And in no case can closing the result set explicitly hurt performance. Yoav Shapira Millennium ChemInformatics -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 10:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/s ql/Statement.html#close( ) (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
In my experience this is not a good recommendation: - -server is less stable than -client in all JDK's that I tried, and this has been confirmed by several list members. - -server won't help much on out of memory errors. The gc is behaving differently, but it can't free more objects, they are just freed at different times. If you get a out of memory error, there rn't any object that can be freed. -Original Message- From: Richard Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:40 PM To: 'Tomcat Users List' Subject: RE: Memory leaks? Try passing the jvm the -server option -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:57 AM To: tomcat Subject: Memory leaks? I seemed to have read that java/tomcat isn't supposed to have memory leaks, but something seems to be running me out of memory and I don't know what. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : Memory leaks?
A question here : why do you put rs.close(), rs = null, stmt.close(), stmt
= null etc twice, in both try and finally statements ?
Since the finally statement is called whenever an exception is thrown or
not, you don't need to close rs, stmt and conn in the try statement
first...
Am I wrong here ?
Thanks
Alain
-Message d'origine-
De : Paul [mailto:[EMAIL PROTECTED]
Envoyé : mercredi, 3. septembre 2003 21:28
À : Tomcat Users List
Objet : Re: Memory leaks?
Docs indicate that leaving a stmt or rs object open can cause memory leaks.
Found the following in the tomcat docs somewhere, i think:
Here is an example of properly written code to use a db connection obtained
from a connection pool:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rs = null;
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement(select ...);
rs = stmt.executeQuery();
... iterate through the result set ...
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close(); // Return to connection pool
conn = null; // Make sure we don't close it twice
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (rs != null) {
try { rs.close(); } catch (SQLException e) { ; }
rs = null;
}
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
}
- Original Message -
From: Jim Lynch [EMAIL PROTECTED]
To: tomcat [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
I seemed to have read that java/tomcat isn't supposed to have memory
leaks, but something seems to be running me out of memory and I don't
know what.
After a number of edit/undeploy/compile/deploy iterations I get the
following:
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
(Big snip)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
at java.lang.Thread.run(Thread.java:536)
root cause
java.lang.OutOfMemoryError
I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java
1.4.1_02.
So where do I start looking for the problem? If I forget to close
Statements would that cause the problem?
Thanks,
Jim.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
Howdy, I completely agree with Senor Einfeldt's comments, having found exactly the same results in my experience with -server. Waiting for Tiger's -server fixes. To the original poster: any objects with dangling references may not be recycled when your app is restarted. These can have bad consequences, such as excessive memory use or stale data, or even tomcat-killing errors such as the dreaded CL: Lifecycle Stopped one ;) You should very carefully inspect your app to close all resources that you can: basically, if it has a public close()/shutdown()/terminate()/whatever function, use it ;) This applies to DB objects, such as the connection/statement/result set/connection pool, but also to others like JMS connections/sessions, mail sessions, transactions, etc. Yoav Shapira Millennium ChemInformatics -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 2:00 AM To: Tomcat Users List Subject: RE: Memory leaks? In my experience this is not a good recommendation: - -server is less stable than -client in all JDK's that I tried, and this has been confirmed by several list members. - -server won't help much on out of memory errors. The gc is behaving differently, but it can't free more objects, they are just freed at different times. If you get a out of memory error, there rn't any object that can be freed. -Original Message- From: Richard Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:40 PM To: 'Tomcat Users List' Subject: RE: Memory leaks? Try passing the jvm the -server option -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:57 AM To: tomcat Subject: Memory leaks? I seemed to have read that java/tomcat isn't supposed to have memory leaks, but something seems to be running me out of memory and I don't know what. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
Howdy, You don't have to close a result set if you're closing the statement right away and the result set is the only one associated with the statement... And in no case can closing the result set explicitly hurt performance. Yoav Shapira Millennium ChemInformatics -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 10:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
But depending on the DB, it can cause problems from the DB with too many open ResultSets... I had an issue with performance testing where everything but ResultSets were being closed and the Oracle DB started throwing errors after about 500 queries. Better safe than sorry. -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 9:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: OK, that's probably what's going on. I know I should close Statements and Connections and do normally but I'm fairly certain I've some out there dangling. I didn't know you had to close ResultSets, however. Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Memory leaks?
I seemed to have read that java/tomcat isn't supposed to have memory leaks, but something seems to be running me out of memory and I don't know what. After a number of edit/undeploy/compile/deploy iterations I get the following: javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) (Big snip) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:536) root cause java.lang.OutOfMemoryError I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java 1.4.1_02. So where do I start looking for the problem? If I forget to close Statements would that cause the problem? Thanks, Jim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
Try passing the jvm the -server option -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:57 AM To: tomcat Subject: Memory leaks? I seemed to have read that java/tomcat isn't supposed to have memory leaks, but something seems to be running me out of memory and I don't know what. After a number of edit/undeploy/compile/deploy iterations I get the following: javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) (Big snip) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne ction(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:619) at java.lang.Thread.run(Thread.java:536) root cause java.lang.OutOfMemoryError I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java 1.4.1_02. So where do I start looking for the problem? If I forget to close Statements would that cause the problem? Thanks, Jim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
Docs indicate that leaving a stmt or rs object open can cause memory leaks.
Found the following in the tomcat docs somewhere, i think:
Here is an example of properly written code to use a db connection obtained
from a connection pool:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rs = null;
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement(select ...);
rs = stmt.executeQuery();
... iterate through the result set ...
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close(); // Return to connection pool
conn = null; // Make sure we don't close it twice
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (rs != null) {
try { rs.close(); } catch (SQLException e) { ; }
rs = null;
}
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
}
- Original Message -
From: Jim Lynch [EMAIL PROTECTED]
To: tomcat [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
I seemed to have read that java/tomcat isn't supposed to have memory
leaks, but something seems to be running me out of memory and I don't
know what.
After a number of edit/undeploy/compile/deploy iterations I get the
following:
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
(Big snip)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
at java.lang.Thread.run(Thread.java:536)
root cause
java.lang.OutOfMemoryError
I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java
1.4.1_02.
So where do I start looking for the problem? If I forget to close
Statements would that cause the problem?
Thanks,
Jim.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
OK, that's probably what's going on. I know I should close Statements
and Connections and do normally but I'm fairly certain I've some out
there dangling. I didn't know you had to close ResultSets, however.
Glad to know that.
Thanks,
Jim.
Paul wrote:
Docs indicate that leaving a stmt or rs object open can cause memory leaks.
Found the following in the tomcat docs somewhere, i think:
Here is an example of properly written code to use a db connection obtained
from a connection pool:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rs = null;
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement(select ...);
rs = stmt.executeQuery();
... iterate through the result set ...
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close(); // Return to connection pool
conn = null; // Make sure we don't close it twice
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (rs != null) {
try { rs.close(); } catch (SQLException e) { ; }
rs = null;
}
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
}
- Original Message -
From: Jim Lynch [EMAIL PROTECTED]
To: tomcat [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
I seemed to have read that java/tomcat isn't supposed to have memory
leaks, but something seems to be running me out of memory and I don't
know what.
After a number of edit/undeploy/compile/deploy iterations I get the
following:
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
(Big snip)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
at java.lang.Thread.run(Thread.java:536)
root cause
java.lang.OutOfMemoryError
I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java
1.4.1_02.
So where do I start looking for the problem? If I forget to close
Statements would that cause the problem?
Thanks,
Jim.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Memory leaks!
Howdy, Umm, where's the memory leak? ;) Do you have any idea at all what could be causing it? Have you even once run your server with a profiler to see where memory is being allocated??? We'll need a lot more information if you want us to seriously look at this... Yoav Shapira Millennium ChemInformatics -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:06 AM To: [EMAIL PROTECTED] Subject: Tomcat Memory leaks! Importance: High Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Memory leaks!
Which JDK version are you using? If you are using JDK1.4.1_02, you might have a memory leak problem (bug#4724129). Try to switch to JDK1.3.1_07 and see whether you still have the same problem. My 2 cents. -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 10:06 PM To: [EMAIL PROTECTED] Subject: Tomcat Memory leaks! Importance: High Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Memory leaks!
Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Memory leaks!
Try the option to fork off the JSP compiles (or even use Jikes to compile). There seems to be a problem with compiling of JSPs that does not use the usual memory you can allocate with the -Xmx type flag... maybe one of the guru's can explain this.. but we had similar problem that whe nwe moved to jikes forked compiles went away... Hope that helps. Cheers, Alex. -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 2:06 PM To: [EMAIL PROTECTED] Subject: Tomcat Memory leaks! Importance: High Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Memory leaks!
Hi. I honestly have no idea what you are talking about. Can you explain what needs to be done for this? You talking about changing `javac`? Thanks -Original Message- From: Alex Burton [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 11:12 PM To: Tomcat Users List Subject: RE: Tomcat Memory leaks! Try the option to fork off the JSP compiles (or even use Jikes to compile). There seems to be a problem with compiling of JSPs that does not use the usual memory you can allocate with the -Xmx type flag... maybe one of the guru's can explain this.. but we had similar problem that whe nwe moved to jikes forked compiles went away... Hope that helps. Cheers, Alex. -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 2:06 PM To: [EMAIL PROTECTED] Subject: Tomcat Memory leaks! Importance: High Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Memory leaks!
Have a look here: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html In your tomcat_home/conf/web.xml you can modify the following like this (assuming you have Jikes installed): servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param init-param param-namefork/param-name param-valuetrue/param-value /init-param init-param param-namecompiler/param-name param-valuejikes/param-value /init-param load-on-startup3/load-on-startup /servlet -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 2:18 PM To: Tomcat Users List Subject: RE: Tomcat Memory leaks! Hi. I honestly have no idea what you are talking about. Can you explain what needs to be done for this? You talking about changing `javac`? Thanks -Original Message- From: Alex Burton [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 11:12 PM To: Tomcat Users List Subject: RE: Tomcat Memory leaks! Try the option to fork off the JSP compiles (or even use Jikes to compile). There seems to be a problem with compiling of JSPs that does not use the usual memory you can allocate with the -Xmx type flag... maybe one of the guru's can explain this.. but we had similar problem that whe nwe moved to jikes forked compiles went away... Hope that helps. Cheers, Alex. -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 2:06 PM To: [EMAIL PROTECTED] Subject: Tomcat Memory leaks! Importance: High Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Memory leaks!
How would setting fork to true change anything? I thought it was the default setting. Am I wrong or is the documentation in web.xml wrong? --Angus -Original Message- From: Alex Burton [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:30 AM To: Tomcat Users List Subject: RE: Tomcat Memory leaks! Have a look here: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html In your tomcat_home/conf/web.xml you can modify the following like this (assuming you have Jikes installed): servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param init-param param-namefork/param-name param-valuetrue/param-value /init-param init-param param-namecompiler/param-name param-valuejikes/param-value /init-param load-on-startup3/load-on-startup /servlet -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 2:18 PM To: Tomcat Users List Subject: RE: Tomcat Memory leaks! Hi. I honestly have no idea what you are talking about. Can you explain what needs to be done for this? You talking about changing `javac`? Thanks -Original Message- From: Alex Burton [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 11:12 PM To: Tomcat Users List Subject: RE: Tomcat Memory leaks! Try the option to fork off the JSP compiles (or even use Jikes to compile). There seems to be a problem with compiling of JSPs that does not use the usual memory you can allocate with the -Xmx type flag... maybe one of the guru's can explain this.. but we had similar problem that whe nwe moved to jikes forked compiles went away... Hope that helps. Cheers, Alex. -Original Message- From: Robert Abbate [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 2:06 PM To: [EMAIL PROTECTED] Subject: Tomcat Memory leaks! Importance: High Hi. It seems Tomcat (4.1.24) has a major memory leak, and I wanted to bring it to the developers attention so they can check it out. I run a shared hosting server (Mandrake 8.2, Apache 1.3) with virtual hosts. I have 1 Gig of RAM and about 50 virtual hosts and yet I keep getting Out of Memory errors! I have made numerous adjustments to memory allocations, yet nothing helps. Here's an example of what I've done: CATALINA_OPTS=-Xmx64mb and CATALINA_OPTS=-Xmx1028mb I can furnish my server.xml file upon request or anything else you may need to fix the problem. Thanks --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mssqlserver jdbc drivers - memory leaks
This is more of an informative e-mail than a problem. I was using the mssqlserver jdbc drivers on both Solaris and Linux platforms. The web application is using lots of @@Identity and inserts into the database. There was an instance to test some stuff that I was attempting lots of inserts ( more than 10,000 ). When attempting to do some logging I got a (Too may open files) exception. Well I changed out the mssqlserver jdbc to an existing JTurbo jdbc license we had and the problem went away. So needless to say there are memory leaks in the microsoft jdbc drivers. I was pulling my hair out over this and I was hoping to spare anybody anguish if possible. Stephen Jackson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.0.2 memory leaks?
Hi, Tomcat 4.0.2 release notes mention a javac memory leak. I checked the archive, but it wasn't clear whether the memory leak problem is a javac (as distributed by SUN in a JDK release) is the root cause. Could someone confirm the javac memory leak problem is tomcat specific or a JDK specific, if JDK, which JDK? ??? That's a leak in javac. Use JspC to compile the JSP if there's a large number of them in your webapp. Remy -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0.2 memory leaks?
Hi Remy, Do you have a link to a javasoft bug report for the javac memory leak? Thanks. Anh At 05:30 PM 2/11/2002 -0800, Remy Maucherat wrote: Hi, Tomcat 4.0.2 release notes mention a javac memory leak. I checked the archive, but it wasn't clear whether the memory leak problem is a javac (as distributed by SUN in a JDK release) is the root cause. Could someone confirm the javac memory leak problem is tomcat specific or a JDK specific, if JDK, which JDK? ??? That's a leak in javac. Use JspC to compile the JSP if there's a large number of them in your webapp. Remy -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: linux + tomcat 3 memory leaks ?
Humm... Did you try the lastest nightly build ? I just happen to have the exact same configuration ( except the kernel ) and everything is running perfectly, much much better than in Tomcat 3.2.4 by the way. ( I strongly recommend the upgrade to everybody !! ) On Sat, 22 Dec 2001 12:52:24 +0100, Dom [EMAIL PROTECTED] escreveu : I've installed Tomcat 3.3 in my linux box After a fresh boot, tomcat launched and NO web application running, I can see that the tomcat user memory is growing regulary by watching Top. Why ? Mandake Linux 7.2 with 2.4.16 kernel (not 2.2.16) Apache 1.3.19 Tomcat 3.3 IBMJava2-13 Dom -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
linux + tomcat 3 memory leaks ?
I've installed Tomcat 3.3 in my linux box After a fresh boot, tomcat launched and NO web application running, I can see that the tomcat user memory is growing regulary by watching Top. Why ? Mandake Linux 7.2 with 2.4.16 kernel (not 2.2.16) Apache 1.3.19 Tomcat 3.3 IBMJava2-13 Dom -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
