*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
--- Begin Message ---
Thanks Chris.  Some useful info I can start looking at.
Yes, it looked like a normal shutdown to me also, all connectors stopped, etc.
The only issue was that I think I should have seen a 3rd servlet announce its 
shutdown in the app log, and it wasn't there.  I'm having the developers look 
into that as the probable cause.
Unfortunately, a test instance starts/stops just fine all day long, so it's not 
reproducible.
I'm not a developer myself, so I'm not fully versed on the available tools for 
getting thread dumps, etc.
Is there a HowTo page for thread dumps or beginner's debugging guide somewhere 
out there?
Jeff

-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, January 15, 2010 9:39 AM
To: Tomcat Users List
Subject: Re: Tomcat crash dump on Windows

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeffrey,

On 1/15/2010 10:21 AM, Jeffrey Janner wrote:
> Is there any procedure for generating a memory dump for Tomcat running
> as a Windows service when the service dies and hangs?

Yes: you want to set one (or more) of the following JVM flags:

- -XX:-HeapDumpOnOutOfMemoryError
- -XX:OnOutOfMemoryError="<cmd args>; <cmd args>"
- -XX:OnError="<cmd args>;<cmd args>"

I'm not sure if you can set "jstack" as the program to run on OOME or
other error... it depends on the current state of the JVM.

A full list of options can be found here:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

> We had a
> production instance stop responding last night and then it refused to
> stop when the operator tried to shut it down using the services control
> panel.  We had to use task manager to kill it.  It started up just fine.
> 
> The log showed stopping messages for 2 out of the 3 servelts, so I'm
> guessing the problem is with the unresponsive servlet, but a memory dump
> would be helpful in determining cause.

You could try traditional thread and/or heap dump techniques before
killing the process. Does that work? I guess you'll have to wait for
another fatal error.

> Some good links to some helpful information is all I'm really looking
> for.
> 
>  
> 
> Also, can anyone shed some light on what the following INFO message
> means from the catalina log:
>    Jan 14, 2010 4:58:35 PM org.apache.catalina.core.StandardWrapper
> unload
> 
>    INFO: Waiting for 13 instance(s) to be deallocated
> 
> Is that just the number of sessions active?  Or something else I should
> look into?

StandardWrapper wraps a lot of things. I've never seen this message
myself, but others have reported this message. It shouldn't be a problem
(notice it's an INFO, not a WARN or ERROR or anything like that).

> 
>  
> 
> Here is the full catalina log from the shutdown.  It looks normal to me
> except for the INFO statements, and the fact that the service never
> actually stopped.
> 
> Jan 14, 2010 4:58:34 PM org.apache.coyote.http11.Http11AprProtocol pause
> 
> INFO: Pausing Coyote HTTP/1.1 on http-172.16.5.1-80
> 
> Jan 14, 2010 4:58:34 PM org.apache.coyote.http11.Http11AprProtocol pause
> 
> INFO: Pausing Coyote HTTP/1.1 on http-172.16.5.1-443
> 
> Jan 14, 2010 4:58:35 PM org.apache.catalina.core.StandardService stop
> 
> INFO: Stopping service GE
> 
> Jan 14, 2010 4:58:35 PM org.apache.catalina.core.StandardWrapper unload
> 
> INFO: Waiting for 13 instance(s) to be deallocated
> 
> Jan 14, 2010 4:58:36 PM org.apache.catalina.core.StandardWrapper unload
> 
> INFO: Waiting for 13 instance(s) to be deallocated
> 
> Jan 14, 2010 4:58:37 PM org.apache.catalina.core.StandardWrapper unload
> 
> INFO: Waiting for 13 instance(s) to be deallocated
> 
> Jan 14, 2010 4:58:38 PM org.apache.coyote.http11.Http11AprProtocol
> destroy
> 
> INFO: Stopping Coyote HTTP/1.1 on http-172.16.5.1-80
> 
> Jan 14, 2010 4:58:38 PM org.apache.coyote.http11.Http11AprProtocol
> destroy
> 
> INFO: Stopping Coyote HTTP/1.1 on http-172.16.5.1-443

This looks like a standard shutdown to me. How many <Connector>s do you
have defined?

I suspect that your webapp is launching a thread that is not set as
daemon=true. When you shutdown Tomcat, it doesn't call System.exit().
Instead, if shuts down all its threads and then exits its main() method.
After that, the JVM should shut down because no other threads are
running... unless your webapp launched some threads that weren't
properly shut down or set as daemon threads.

A thread dump will definitely help, here. You ought to be able to just
attempt to shut down Tomcat, see that it's still running (the JVM is
really still running, not Tomcat), and then take a thread dump. It will
show you the threads still running. Anything that doesn't say
daemon=true will be preventing the JVM from shutting down.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktQjBAACgkQ9CaO5/Lv0PDazQCfT2q/PD8Ysc2HqsGicyzCNfaQ
wxoAn0puhLbAQ3MSVfZw/iiHSrcstbET
=TRCc
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to