tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolaos Giannopoulos" <nikol...@solmar.ca>
Subject RE: Determining JVM stability
Date Wed, 28 May 2003 19:46:03 GMT
Yoav,


> -----Original Message-----
> From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
> Sent: Tuesday, May 27, 2003 10:06 AM
>
>
> Howdy,
> If the JVM crashes due to its own internal fault, it produces two things
> on Solaris:
> 1. A core file with a traditional core dump... Google the web for
> analysis tools for these files, but it's nasty and you likely don't need
> to do it, because:

We find no core dumps when scanning the file system.


> 2. A file named hs_err_[pid].txt where [pid] is the JVM process ID when
> it was crashing.  The file will be in the current working directory for
> the JVM, so wherever you started it from.  The file will list what the
> JVM was doing when it was crashing, what libraries were loaded, and
> other helpful information.  You can put this file on the BugParade when
> opening a new JVM bug issue with Sun.

No hotspot error files either.


> If the hs_err file is not there, it wasn't an internal JVM crash, but
> rather a problem in your code.  (Or, unlikely but possible, a crash in
> tomcat).  If this is the case, post your stack traces and maybe we can
> help more.

Actually we may have figured this one out and by end of day tomorrow we will
know for sure.

We have 4 servers in all running the same software.  There is no problem
with the code as it is the same software running on all 4 tiers - in fact we
even copied over all application software from a working tier to rule out
any possibility of a corrupt file or something thereof.

In Nov 2002 we saw the same issue that we are seeing now with an older 5th
box.  The only commonality between the 2 boxes is that they both have had
their OS's upgraded from Solaris 2.6 to 8.  The other boxes are clean
installs of Solaris 8.

We saw this issue on clean installed Solaris 8 boxes until we installed the
Java patch for 1.4.1_01 (Patch version 61) and then the issue would go away.
In Nov 2002 on the upgraded box the patch did not help.  And on the box that
we are seeing the problem now the patch does not help as well.

This leads me to believe that the Java patch (61) works well on a system
with Solaris 8 cleanly installed on it BUT not a system that was upgraded
from Solaris 2.6 to 8.  It could be - I'm guessing - that in the upgrade
process a older library (from 2.6) is not overwritten (with an 8 version) as
the Java patch expects.

The only thing that is quite weird is that in both cases the boxes had been
upgraded about 3 months *before* we started seeing any problems.  Why this
is the case is not clear nor may it ever be clear.

Once again this is the theory as flaky as it may sound.



> >-----Original Message-----
> >From: Nikolaos Giannopoulos [mailto:nikolaos@solmar.ca]
> >Sent: Friday, May 23, 2003 5:26 PM
> >To: Tomcat Users
> >Subject: Determining JVM stability
> >
> >We have a Solaris 8 (sparc) production box at patch level 17 (java
> patch
> >level 61) and we are seeing Tomcat (jdk 1.4.1_01) processes and
> application
> >processes (jre 1.4.1_01) simply dissappear!
> >
> >The tomcat logs show a rather generic exception that starts in
> Thread.run()
> >
> >Anyone know of OR have seen any problems of this nature?
> >
> >Anyone know of a tool or software component that can verify that in
> fact
> >there is a problem (i.e. that the JVM is crashing) with the underlying
> OS
> >libraries or something thereof.  Maybe there's a default JVM switch
> that
> >could be turned on to spit out debug info before it dies.
> >
> >Any ideas are totally welcome... (barring rebuild the OS that is).
> >
> >Thanks,
> >
> >--Nikolaos
> >
> >
> >2003-05-16 11:21:26 CoyoteAdapter An exception or error occurred in the
> >container during the request processing
> >java.lang.NullPointerException
> >        at
> >org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve
> .jav
> >a
> >:164)
> >        at
> >org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invo
> >k
> >eNext(StandardPipeline.java:643)
> >        at
> >org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
> 480)
> >        at
> >org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> >        at
> >org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
> >        at
> >org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:4
> 32)
> >        at
> >org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process
> Conn
> >e
> >ction(Http11Protocol.java:386)
> >        at
> >org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:5
> 34)
> >        at
> >org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPoo
> l.ja
> >v
> >a:530)
> >        at java.lang.Thread.run(Thread.java:536)
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message