>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:
[EMAIL PROTECTED]: 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
