Re: Automatic Thread Dump configuration
En l'instant précis du 17/01/08 15:46, Chad Kellerman s'exprimait en ces termes: Tomcat Users, I have been googling Tomcat thread dumps and have not seen what I want to accomplish anywhere... Is there a way to configure Tomcat to execute a thread dump whenever there is an Out Of Memory issue or if an app reached the max thread count? When there is an OutOfMemory, it's impossible to make a ThreadDump. The reason is that, since you lack memory, it can be seen as useless to try allocating StackTrace object and stuff it in a new Error(). Moreover, from my experience, when you are out of memory, the location where you are out if generally irrelevant, as it's most of the time cause by a memory leak somewhere else. As for you max ThreadDump, you could still try feeding the tomcat output to an external tool that sends a Kill -3 to tomcat Thre when it sees some keyword. Note that, in both cases, it's not tomcat's job to make a ThreadDump, it's more related to jvm behaviour. Other vendors than sun might have some facilities for that? I am using Tomcat 5.5.25 on RHEL 5. with jdk1.5.0_13 Thanks for the help, Chad -- http://www.devlog.be (a belgian developer's logs) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic Thread Dump configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David Delbecq wrote: | En l'instant précis du 17/01/08 15:46, Chad Kellerman s'exprimait en ces | termes: | Tomcat Users, | I have been googling Tomcat thread dumps and have not seen what I | want | to accomplish anywhere... | |Is there a way to configure Tomcat to execute a thread dump whenever | there is an Out Of Memory issue or if an app reached the max thread | count? Since an OOME is a Throwable, any stack trace that is available will be dumped to standard output. Often, there is no stack trace available, so you don't get one. | When there is an OutOfMemory, it's impossible to make a ThreadDump. The | reason is that, since you lack memory, it can be seen as useless to try | allocating StackTrace object and stuff it in a new Error(). Moreover, | from my experience, when you are out of memory, the location where you | are out if generally irrelevant, as it's most of the time cause by a | memory leak somewhere else. True. On the other hand, you /can/ get a heap dump if you're using Sun's Java 1.6.x using this JVM option: - -XX:+HeapDumpOnOutOfMemoryError - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkePkQMACgkQ9CaO5/Lv0PAZrwCgnCnVc7BJZ/UOqY8ZAFkD3Lp6 WAkAn0HWiUh2ijXWfnzFTJoaI2kTlUYu =ZY/C -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic Thread Dump configuration
Christopher Schultz schrieb: | When there is an OutOfMemory, it's impossible to make a ThreadDump. The | reason is that, since you lack memory, it can be seen as useless to try | allocating StackTrace object and stuff it in a new Error(). Moreover, | from my experience, when you are out of memory, the location where you | are out if generally irrelevant, as it's most of the time cause by a | memory leak somewhere else. True. On the other hand, you /can/ get a heap dump if you're using Sun's Java 1.6.x using this JVM option: -XX:+HeapDumpOnOutOfMemoryError -chris ... and also for 1.4.2_12+ or 1.5.0_07+ (although in combination with parallel young GC better with 1.4.2_15+). In addition there is: -XX:HeapDumpPath=FILENAME FILENAME, if relative, will be relative to the working directory, for Tomcat relative to bin/. For Java 6 (and I think also recent 1.4.2 but maybe not Java 5) there is also -XX:OnOutOfMemoryError=command. You could experiment with putting a kill -QUIT to your process into the command script. Don't know, if the externally triggered thread dump needs Java memory allocation. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
