DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33371>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 Summary: Errors are not reported to user code (servlets). Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, There is a problem with mod_jk and Tomcat under high load that causes slots to be kept by Apache even though the backend Tomcat links has gone down. This is caused by too eager user aborts, ie. where you have web clients that abort the connection by just closing it. You get a broken pipe on the Tomcat side and eventually that is cleared out - since under less traffic this is not an issue. Now consider that you get hammered with requests and many are aborted, ie. out of 30 per seconds 10 are aborted. There are two issues with that, both I will list as separate reports: 1. Reporting errors to user code 2. Closing connections We use Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d mod_jk/1.2.6 and Tomcat 5.0.28 This report is for problem #1 above. Consider this error taken from the catalina.out: Nov 30, 2004 2:51:17 PM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:508) at org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:401) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:416) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:230) at org.apache.coyote.Response.doWrite(Response.java:542) at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:368) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:398) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:318) at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297) at org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:85) at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:410) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at java.io.BufferedWriter.flush(BufferedWriter.java:230) at org.apache.axis.Message.writeTo(Message.java:441) at org.apache.axis.transport.http.AxisServlet.sendResponse(AxisServlet.java:1018) at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:895) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312) at com.worldlingo.servlet.MSOfficeApi11Servlet.service(MSOfficeApi11Servlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) 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.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) 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.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) 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.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:691) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) The bug here - or rather design flaw - is that the user code will never know what happened and log this as a successful response. Why? Because this line at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:508) throw the exception but this line: at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:416) swallows the exception, which means, the calling code never knows that an IO exception was thrown. The flaw ist that the action() method does not pass on the exception, ie. it should be declared public void action(ActionCode actionCode, Object param) throws IOException { ... just like the send() call. This also applies to the matching action() method of org.apache.coyote.Response The JKCoyoteHandler.doWrite() declares the IOException and passes it on. So that part is OK. Especially with the SOAP calls like in the example above, where you have small messages, it may happen the the whole message is written out in the flush() call to the stream nd if that error is just logged but not reported, the servlet will never know. Regards, Lars George, CTO WorldLingo -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
