Have you tried turning off the HotSpot JIT compiler and trying your test? All other things being equal, this will show you that the problem resides in the interaction between Tomcat and the compiled code.
Just a thought... Ben Ricker On Wed, 2002-12-11 at 08:44, Aymeric Alibert wrote: > I changed the debug flag to 10 in all elements of my server.xml. > Looking at the log file, I cannot identifiy any error or warning from > Tomcat before it crashes. > Here is a sample: > > ... > StandardContext[/residential]: Mapped to servlet 'default' with servlet path >'/images/home_hdr.jpg' and path info 'null' and update=true > StandardEngine[Standalone]: Mapping server name 'trngyouraccount.alliant-energy.com' > StandardEngine[Standalone]: Trying a direct match > StandardEngine[Standalone]: Trying an alias match > StandardHost[localhost]: Mapping request URI '/residential/images/dropshadow.gif' > StandardHost[localhost]: Trying the longest context path prefix > StandardHost[localhost]: Mapped to context '/residential' > Authenticator[/residential]: Security checking request GET >/residential/images/dropshadow.gif > Authenticator[/residential]: Checking constraint 'SecurityConstraint[youraccount >assistance LDAP authentication]' against GET /images/dropshadow.gif --> false > Authenticator[/residential]: No applicable constraint located > Authenticator[/residential]: Not subject to any constraint > StandardContext[/residential]: Mapping contextPath='/residential' with >requestURI='/residential/images/dropshadow.gif' and >relativeURI='/images/dropshadow.gif' > StandardContext[/residential]: Trying exact match > StandardContext[/residential]: Trying prefix match > StandardContext[/residential]: Trying extension match > StandardContext[/residential]: Trying default match > StandardContext[/residential]: Mapped to servlet 'default' with servlet path >'/images/dropshadow.gif' and path info 'null' and update=true > StandardEngine[Standalone]: Mapping server name 'trngyouraccount.alliant-energy.com' > StandardEngine[Standalone]: Trying a direct match > StandardEngine[Standalone]: Trying an alias match > StandardHost[localhost]: Mapping request URI '/residential/images/homepa2.gif' > StandardHost[localhost]: Trying the longest context path prefix > StandardHost[localhost]: Mapped to context '/residential' > Authenticator[/residential]: Security checking request GET >/residential/images/homepa2.gif > Authenticator[/residential]: Checking constraint 'SecurityConstraint[youraccount >assistance LDAP authentication]' against GET /images/homepa2.gif --> false > Authenticator[/residential]: No applicable constraint located > Authenticator[/residential]: Not subject to any constraint > StandardContext[/residential]: Mapping contextPath='/residential' with >requestURI='/residential/images/homepa2.gif' and relativeURI='/images/homepa2.gif' > StandardContext[/residential]: Trying exact match > StandardContext[/residential]: Trying prefix match > StandardContext[/residential]: Trying extension match > StandardContext[/residential]: Trying default match > StandardContext[/residential]: Mapped to servlet 'default' with servlet path >'/images/homepa2.gif' and path info 'null' and update=true > StandardEngine[Standalone]: Mapping server name 'trngyouraccount.alliant-energy.com' > StandardEngine[Standalone]: Trying a direct match > StandardEngine[Standalone]: Trying an alias match > StandardHost[localhost]: Mapping request URI '/residential/images/_c60b27.gif' > StandardHost[localhost]: Trying the longest context path prefix > StandardHost[localhost]: Mapped to context '/residential' > Authenticator[/residential]: Security checking request GET >/residential/images/_c60b27.gif > Authenticator[/residential]: Checking constraint 'SecurityConstraint[youraccount >assistance LDAP authentication]' against GET /images/_c60b27.gif --> false > Authenticator[/residential]: No applicable constraint located > Authenticator[/residential]: Not subject to any constraint > StandardContext[/residential]: Mapping contextPath='/residential' with >requestURI='/residential/images/_c60b27.gif' and relativeURI='/images/_c60b27.gif' > StandardContext[/residential]: Trying exact match > StandardContext[/residential]: Trying prefix match > StandardContext[/residential]: Trying extension match > > Unexpected Signal : 11 occurred at PC=0xFFFFFFFF3981797C > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > > Dynamic libraries: > 0x100000000 /SunQA/youraccount/j2sdk1.4.1_01/bin/sparcv9/java > 0xffffffff7f200000 /usr/lib/64/libthread.so.1 > 0xffffffff7f400000 /usr/lib/64/libdl.so.1 > 0xffffffff7ef00000 /usr/lib/64/libc.so.1 > 0xffffffff7ed00000 /usr/platform/SUNW,Ultra-4/lib/sparcv9/libc_psr.so.1 > 0xffffffff7d000000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/server/libjvm.so > 0xffffffff7d800000 /usr/lib/64/libCrun.so.1 > 0xffffffff7cd00000 /usr/lib/64/libsocket.so.1 > 0xffffffff7cb00000 /usr/lib/64/libnsl.so.1 > 0xffffffff7c900000 /usr/lib/64/libm.so.1 > 0xffffffff7da00000 /usr/lib/64/libw.so.1 > 0xffffffff7c600000 /usr/lib/64/libmp.so.2 > 0xffffffff7c300000 >/SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/native_threads/libhpi.so > 0xffffffff7c000000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libverify.so > 0xffffffff7be00000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libjava.so > 0xffffffff7bb00000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libzip.so > 0xffffffff13a00000 /usr/lib/locale/en_US.ISO8859-1/sparcv9/en_US.ISO8859-1.so.2 > 0xffffffff10a00000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libnet.so > > Local Time = Tue Oct 31 11:58:52 2000 > Elapsed Time = 317 > # > # HotSpot Virtual Machine Error : 11 > # Error ID : 4F530E43505002E6 01 > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.1_01-b01 mixed mode) > # > # An error report file has been saved as hs_err_pid1694.log. > # Please refer to the file for further information. > # > > > > >>> [EMAIL PROTECTED] 12/10/02 06:53PM >>> > Have you try running your test and verbosing as much as possible > information inside the log file (increase the debug level in > server.xml)? Try it to see if Tomcat 4.1.x output something useful to > trace the problem. Post your result (ot the last couple of lines). Maybe > it will help. > > -- Jeanfrancois > > Aymeric Alibert wrote: > > > Thanks for the feedback. > > > > When I ran my load tests I used -Xmx512m -Xms512m as heap settings. > > I also tried increasing or decreasing it but it didn't change the results. > > I am running on Solaris and I have all the recommended patches for > > JDK1.4.1 installed. > > > > I can reproduce the problem: it is always crashing during the test, > > but it can be after 2 minutes or 20 minutes depending on the run. > > My problem is that I cannot create a simple test case that will crash the > > server because of the complexity of our environment ( it includes > > multiples > > Oracle databases and LDAP connectivity). > > I tried to isolate the problem to a single jsp like you recommend > > it but that didn't work. > > (I could fine several combinations that would trigger the crash). > > So I am not sure what I could provide as a test case except our full > > dev environment. > > > > I can deploy the same application on TC4.0.4 and it runs fine. I tried > > many versions > > of Tomcat 4.1 (4.1.7, 4.1.12, 4.1.14 and 4.1.16) and are all failing. > > > > I attached the VM log. > > > > Thanks, > > > > > > Aymeric > > > > > > > > >>> [EMAIL PROTECTED] 12/10/02 04:48PM >>> > > Howdy, > > If your OS requires patches in order to run the JDK (whatever version > > you're trying to run), make sure those patches are installed. I had > > this exact issue happen on Solaris, and installing the proper Solaris > > patches made it go away. > > > > You say "The same behavior can be reproduced with both JDK1.4.0 and > > JDK1.4.1" and yet "I cannot create a test case to reproduce my problem." > > Which one is it? ;) If you can reproduce it, the full details of how > > to reproduce it can be posted to Sun's bug parade, and they'll track > > down whatever tools they need in order to mimic your environment. If > > you can't reproduce it, there's no bug as far as they're concerned. > > > > Finally, I'm not sure I understand this bullet: > > > > >- I works fine with TC4.1 > > > > So your app works fine on TC 4.1? I thought that was the whole problem? > > Or did you mean it works fine with TC 4.0 and not 4.1? If it's the > > latter, as I suspect, perhaps you could start by deploying a very small > > subset of your app and repeating the test. Then increase the deployed > > subset and retest. The idea is that a certain feature of tomcat as used > > by your app is crashing the VM, and to find out which section of your > > app is causing this. The more you can narrow it down, the better. > > > > Yoav Shapira > > Millennium ChemInformatics > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > >------------------------------------------------------------------------ > > > >-- > >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- Ben Ricker <[EMAIL PROTECTED]> Wellinx.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
