tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: Determining JVM stability
Date Wed, 28 May 2003 19:45:37 GMT

Howdy,
I've heard flakier theories for sure, would be interested to know your
final conclusions...

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Nikolaos Giannopoulos [mailto:nikolaos@solmar.ca]
>Sent: Wednesday, May 28, 2003 3:46 PM
>To: Tomcat Users List
>Subject: RE: Determining JVM stability
>
>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




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


Mime
View raw message