You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Leon Rosenberg <ro...@googlemail.com> on 2006/02/28 22:36:13 UTC
Tomcat silently stops working, very strange exceptions in catalina.out
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
Re: Tomcat silently stops working, very strange exceptions in catalina.out
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 2/28/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> >javax.servlet.jsp.JspException: No bean found under attribute key result
>
> this is a regular struts exception, it is expecting a bean in one of the
> scopes (request,page,session), but it is not there.
'The funny thing is, that there is actually no way for the bean to
"not be there"...
the code from the appropriate action looks like this:
if (!r.isValid()) {
if(r.getErrorMessage() != null && r.getErrorMessage().startsWith("PLZ")) {
errors.add("search", new ActionError("errors.zip.notexisting"));
} else {
throw new RuntimeException("Query failed:
"+IResultStatus.STATUS_DESC[r.getStatus()]+"("+r.getErrorMessage()+")");
}
} else {
ResultBean result = new ResultBean();
... omitted...
addBeanToSession(req, ISessionConstantsNames.SEARCH_BEAN_RESULT, result);
addBeanToSession(req,
ISessionConstantsNames.SEARCH_BEAN_LAST_QUERY, r.getSourceQuery());
}
if(errors.size() > 0) {
saveErrors(req, errors);
proceedErrorHandling(req);
return mapping.getInputForward();
}
return mapping.findForward(view); <-- only this return leads to the
jsp in the logs.
if the jsp-in-question mapping is returned, the ResultBean must be in
session, or the session is corrupted.
>
> your second error seems to be a result of a client disconnecting
>
> http://tomcat.apache.org/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/connector/ClientAbortException.html
Sure, but that doesn't explain why tomcat stops responding, does it?
>
> Filip
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat silently stops working, very strange exceptions in catalina.out
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
>javax.servlet.jsp.JspException: No bean found under attribute key result
this is a regular struts exception, it is expecting a bean in one of the
scopes (request,page,session), but it is not there.
your second error seems to be a result of a client disconnecting
http://tomcat.apache.org/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/connector/ClientAbortException.html
Filip
Leon Rosenberg wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org