tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <rosenberg.l...@googlemail.com>
Subject Tomcat silently stops working, very strange exceptions in catalina.out
Date Tue, 28 Feb 2006 21:36:13 GMT
Hi,

I'm seeing a strange behaviour of tomcat (once more :-)) which I can't explain.
At some point of time and without a recognizable reason beans start to
vanish from the request scope. The catalina.out is then full of
exceptions like:

StandardWrapperValve[controller]: Servlet.service() for servlet
controller threw exception
javax.servlet.jsp.JspException: No bean found under attribute key result
javax.servlet.jsp.JspException: No bean found under attribute key result
	at org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagBase.java:221)
	at org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90)
	at org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(ConditionalTagBase.java:218)
	at org.apache.jsp.ourjsp....SimpleSearchResult_jsp._jspx_meth_logic_equal_3(SimpleSearchResult_jsp.java:3858)

I have never saw this exception before on the same production system.
Actually it can't happen, because if the action (struts based webapp)
fails to construct and put the result bean into the request it
redirects to an error page, and not to the result presentation page.

Further I see:

org.apache.catalina.core.StandardHostValve@51107b: Exception
Processing ErrorPage[errorCode=500, location=/down/500.html]
ClientAbortException:  java.net.SocketException: Broken pipe
	at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:331)
	at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297)
	at org.apache.coyote.tomcat5.CoyoteResponse.flushBuffer(CoyoteResponse.java:537)
	at org.apache.coyote.tomcat5.CoyoteResponseFacade.flushBuffer(CoyoteResponseFacade.java:238)
	at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:303)
	at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:244)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:793)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:702)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:571)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644)
	at java.lang.Thread.run(Thread.java:534)

Less frequent, but also many


And finally:

Fatal: Stack size too small. Use 'java -Xss' to increase default stack size.

The system: linux debian, kernel 2.6., intel p4 or xeon and amd
machines, tomcat 5.0.25,
jdk14.2._04.

tomcat is started with following JAVA_OPTS:
export JAVA_OPTS="-server -mx1200M -ms1200M -Djacorb.config.dir=conf -Djacorb.ho
me=$JACORB_HOME -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBS
ingletonClass=org.jacorb.orb.ORBSingleton -Djavax.net.ssl.trustStore=$HOME/.keys
tore -Djavax.net.ssl.trustStorePassword=XXX"

Further interesting detail:
One of the machines was upgraded to jdk1.5_06 today (for testing
purposes). It wasn't affected, however, as we stopped it, the server
dying stoped two. We started it again, and two further servers died
immediately. We stopped and restarted it later again, and it's running
normally now. The server dying was at our daily peak-traffic time.
However we had 20-30% more peak traffic on the same webpool without
any server crashes (but without 1.5. either).

The webservers aren't communicating with each other, but the backend
sends events (in form of serialized java classes) to the servers.
Everything is 1.4 compiled.

thanx in advance
Leon

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


Mime
View raw message