Thanks for Peter, the hardware is the same box with production machine, 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. 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. 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. thanks.
Best regards, Jochen On Thu, Apr 23, 2009 at 2:36 PM, Peter Crowther <peter.crowt...@melandra.com > wrote: > > From: jochen [mailto:songzhou...@gmail.com] > > I deployed an inhouse application in Tomcat 6.0 and I > > experienced random JVM crashes for two weeks. > > Are you *absolutely certain* your hardware is good? We've had several > reports of JVM crashes on this list where the real problem is faulty > hardware - usually bad RAM. It's far more common than most people realise. > Test by running the application on different hardware. > > [...] > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM > > code, C=native code) > > V [libjvm.so+0x3678c8] > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > > v ~BufferBlob::Interpreter > [...] > > java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/ > > Object;)Ljava/lang/Object; > > v ~BufferBlob::Interpreter > > J > > com.opensymphony.xwork2.DefaultActionInvocation.invoke()Ljava/ > lang/String; > [...] > > The code that is closest to the crash is this OpenSymphony code, which is > then invoking something by reflection when the crash happens. > > Do the crashes always happen at the same point in the code? If so, I'd ask > OpenSymphony :-). If not, I suspect bad hardware - but you might want to > analyse several crash dumps to look for common factors. > > - Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
