You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pieter Temmerman <pt...@sadiel.es> on 2009/02/04 15:23:32 UTC
Re: Thread dump analysis
Hi.
For all of you who were so kind to respond to my problem a few days ago,
and for others who'd like to know, I think I have found the problem.
As mentioned in earlier mails, the application I monitor hangs after a
random amount of time. Using jconsole and virtualvm I managed to detect
the threads that were causing the hangup and showed the following in
their stacktraces:
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl
$PrologDriver.next(XMLDocumentScannerImpl.java:930)
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
> com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:548)
Now, I don't know why (since I'm a noob programmer), but it seems that
the implementation of Xerces that is included in JDK6 is causing the
application to hang. Using JDK5 I don't see this behavior. (Off-topic:
is it discouraged to use TC6 with JDK5?).
The problem might be reside in Xerces implementation or rather an
incompatibility issue between JDK6 and XFire (I haven't found any
indications for that).
The thing is, using JDK5, I don't see any Xerces threads anymore that
are continuously running.
Cheers.
Pieter
On Wed, 2009-01-28 at 18:13 +0100, Pieter Temmerman wrote:
> Thanks Chris,
>
> I just bumped into a very nice plugin for Jconsole called "TopThread".
> It's a linux top alike and shows the CPU usage of all threads.
> This only confirms what I figured out before, there are two threads
> taking up all CPU. See below for their stack trace:
>
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl
> $PrologDriver.next(XMLDocumentScannerImpl.java:930)
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
> com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:548)
> <<<<<-------->>>>IT SEEMS THE ABOVE PART IS REPORTEDLY EXECUTED BY THE
> BELOW LINE<<<<<-------->>>>>
> org.codehaus.xfire.soap.handler.ReadHeadersHandler.invoke(ReadHeadersHandler.java:44)
> org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
> org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64)
> org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38)
> org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireServletController.java:304)
> org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:129)
> org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java:116)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> org.apache.coyote.http11.Http11Protocol
> $Http11ConnectionHandler.process(Http11Protocol.java:583)
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> java.lang.Thread.run(Thread.java:619)
>
>
> Also, I noticed something else..
> After a while (15-20mins) the webapp is accessible again (without
> restarting Tomcat), although CPU usage keeps hitting 100%. Could it be
> that Tomcat ran out of connectors (maxThreads was hit) and after a while
> they get closed by the timeout?
> This could be a plausible explanation, although, the weird thing still
> is why this coincides with the CPU topping 100%.
>
> Still puzzled :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Pieter Temmerman
email: ptemmerman.ext@sadiel.es
skype: ptemmerman.sadiel
SADIEL TECNOLOGÍAS DE LA INFORMACIÓN, S.A. http://www.sadiel.es.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Thread dump analysis
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Pieter Temmerman [mailto:ptemmerman.ext@sadiel.es]
> Subject: RE: Thread dump analysis
>
> And what about Tomcat 5 with JDK6?
I don't run Tomcat 5 much anymore, but what little I have done with it seems to be fine on JDK 6.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Thread dump analysis
Posted by Pieter Temmerman <pt...@sadiel.es>.
Charles, List,
>Hmmm... could be a JVM bug, or might be a conflict with classes in your webapp. Do you happen to have some XML-related jars in >your webapp or otherwise visible to that branch of the classloader tree? (I guess you answered that below.)
Well, actually, the developers also included an Apache Xerces library (note that the other Xerces library is Sun's implementation). Apart from that, as you mentioned below there are XFire related libraries.
>No, JDK5 works fine with Tomcat 6. The newer JVM is a bit faster, in many cases.
Good to know. And what about Tomcat 5 with JDK6?
>It looks like XFire has been superseded by CXF; have you tried that?
>http://xfire.codehaus.org/
>http://cxf.apache.org/
Yes, I also noticed that CXF was the way to go, unfortunately this application has not been developed by me and is closed source, so the only option is to use it as it is..with XFire.
I mailed both XFire and Sun's mailinglist a few days ago, but unfortunately I'm still waiting for a reply.
I guess I'll just have to deal with the fact that it doesn't work with JDK6, although I don't know why.
Anyway, many thanks to all of you for helping me out. It's kindly appreciated.
Regards,
Pieter
RE: Thread dump analysis
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Pieter Temmerman [mailto:ptemmerman.ext@sadiel.es]
> Subject: Re: Thread dump analysis
>
> Now, I don't know why (since I'm a noob programmer), but it seems that
> the implementation of Xerces that is included in JDK6 is causing the
> application to hang.
Hmmm... could be a JVM bug, or might be a conflict with classes in your webapp. Do you happen to have some XML-related jars in your webapp or otherwise visible to that branch of the classloader tree? (I guess you answered that below.)
> Off-topic: is it discouraged to use TC6 with JDK5?
No, JDK5 works fine with Tomcat 6. The newer JVM is a bit faster, in many cases.
> The problem might be reside in Xerces implementation or rather an
> incompatibility issue between JDK6 and XFire (I haven't found any
> indications for that).
It looks like XFire has been superseded by CXF; have you tried that?
http://xfire.codehaus.org/
http://cxf.apache.org/
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org