chris, The hardware has same identical spec with others, and hosting for internet service independent, and the model of hardware is very popular and proven to be used in internet service, of course, it still needs check to ensure its quality. I will ask hardware team for help to check that points you mentioned, perhaps a long-time hardware test is needed.
No JNI frames in the stack dump also confused me a lot, but "LJava/lang/String" was one of parameter structure defined by our C code. I don't know if any other Java code including JDK, tomcat, or struts, would define the structure like this, if have, please remind me. On Thu, Apr 23, 2009 at 11:16 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jochen, > > On 4/23/2009 4:14 AM, jochen wrote: > > Thanks for Peter, the hardware is the same box with production > > machine > > Do you mean the same physical machine, or a machine with identical > specs? If the former, that's bad. If the latter, that's good, but > irrelevant. You might just have drawn the short straw on some RAM. > > > and those type of machines works very well for serving large-load > > internet service, and the hardware itself already hosted very well > > for half year before I deployed new functions to it. > > You wouldn't be the first one to experience hardware failure after > things were running well. Seriously, if you can't blame this on your JNI > code, just test the hardware. You can spend months looking at code and > finding nothing if your hardware has gone bad. Do yourself a favor and > run a hardware test -- you can even run it overnight and sleep while the > work is being done for you :) > > > Again the new functions worked fine for several days, and crashed > > twice. It seemed the crashes always happen at the same point of those > > new function code, not in xwork2. > > Interesting. > > > Your reply reminds me on the > > "DefaultActionInvocation.invoke()Ljava/lang/String", maybe it is the > > fault of JNI code, which was invoked by xwork2, to call some native C > > code to finish something jobs. I'll try to reproduce it and confirm > > if it's the JNI fault. > > I didn't see any JNI frames in the stack dump, but it's possible that > you have JNI code that is mangling something in memory and the JVM later > goes in and tries to de-reference it, and you get a SIGSEGV. > > Are you actually running any of your own native code? > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAknwhlwACgkQ9CaO5/Lv0PBkXwCgmx7aYdrf8q7JZ5xuxvTyYNDs > LvoAn3kbaT69rSiBhe4RAOypSlQffxNi > =m2r0 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
