Re: POST request processing failure
Hah! Back many months ago the problem you are reporting would cause an infinite loop in the Processor. So I fixed the infinite loop bug and added code to report when these POST problems occur. I don't know what the source of the problem is, perhaps the remote client is aborting the connection before the POST completes? If you find out the source of the problem please let me know! Regards, Glenn Rossen Raykov wrote: I have Tomcat 4.0.4/Struts 1.0.2 with Apache 1.3.26 connected by mod_jk/1.2.0, ajp13 protocol, running on Sparc Solaris 8. The problem that I have is that from time to time there are 500 errors in my Apache log. The corresponding error on Tomcat side is: java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length A complete trace is included in the bottom of the e-mail. This only happens during POST request. According to the log it happened with many different browsers including MSIE 5 and 6 and different Netscape flavors, that's why I believe this is not a browser related issue. The logged posted data size is either 4276 or 1024 bytes and the reported time processing varies from 1 to more than 7000 seconds! I saw some similar postages but without any useful answers or comments. Is that a known/common bug and is there any solution for it? Regards, Rossen --- COMPLETE ERROR TRACE - java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length at org.apache.catalina.connector.HttpRequestBase.parseParameters(HttpRequestBas e.java:658) at org.apache.catalina.connector.HttpRequestBase.getParameterNames(HttpRequestB ase.java:723) at org.apache.catalina.connector.RequestFacade.getParameterNames(RequestFacade. java:165) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743) at org.apache.struts.action.ActionServlet.processPopulate(ActionServlet.java:20 61) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564) at org.apache.struts.action.SecureActionServlet.process(D:/CvsProjects/StrutsEx tTry/src/org/apache/struts/action/SecureActionServlet.java:97) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:475) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:2 46) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66)
RE: POST request processing failure
I suspected that this may be related to that old issue since it disappeared after the upgrade to 4.0.4. I believe it is connected to the ajp13 protocol but I can not prove it. The strangest thing is the length of the posted request - it is always power of 1K. BW you said that you fix the Processor but how you are detecting that the connection to the httpd is closed without any changes in the C binary? As I remember in the old version of this bug there was an infinite data exchange between the httpd and Tomcat. At that time trus was reporting something like: 0.0703 recv(26, 0xFFBEE4A0, 4, 0) = 4 0xFFBEE4A0: A B\003 0.0710 recv(26, 0x0025D888, 3, 0) = 3 0x0025D888: 061FFA 0.0715 send(26, 0x0025F890, 4, 0) = 4 0x0025F890: 12 4\0\0 0.0720 recv(26, 0xFFBEE4A0, 4, 0) = 4 0xFFBEE4A0: A B\003 0.0723 recv(26, 0x0025D888, 3, 0) = 3 0x0025D888: 061FFA 0.0727 send(26, 0x0025F890, 4, 0) = 4 Was this completely because tomcat connector only? Regards, Rossen -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 11:06 AM To: Tomcat Users List Subject: Re: POST request processing failure Hah! Back many months ago the problem you are reporting would cause an infinite loop in the Processor. So I fixed the infinite loop bug and added code to report when these POST problems occur. I don't know what the source of the problem is, perhaps the remote client is aborting the connection before the POST completes? If you find out the source of the problem please let me know! Regards, Glenn Rossen Raykov wrote: I have Tomcat 4.0.4/Struts 1.0.2 with Apache 1.3.26 connected by mod_jk/1.2.0, ajp13 protocol, running on Sparc Solaris 8. The problem that I have is that from time to time there are 500 errors in my Apache log. The corresponding error on Tomcat side is: java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length A complete trace is included in the bottom of the e-mail. This only happens during POST request. According to the log it happened with many different browsers including MSIE 5 and 6 and different Netscape flavors, that's why I believe this is not a browser related issue. The logged posted data size is either 4276 or 1024 bytes and the reported time processing varies from 1 to more than 7000 seconds! I saw some similar postages but without any useful answers or comments. Is that a known/common bug and is there any solution for it? Regards, Rossen --- COMPLETE ERROR TRACE - java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length at org.apache.catalina.connector.HttpRequestBase.parseParameters( HttpRequestBas e.java:658) at org.apache.catalina.connector.HttpRequestBase.getParameterName s(HttpRequestB ase.java:723) at org.apache.catalina.connector.RequestFacade.getParameterNames( RequestFacade. java:165) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743) at org.apache.struts.action.ActionServlet.processPopulate(ActionS ervlet.java:20 61) at org.apache.struts.action.ActionServlet.process(ActionServlet.j ava:1564) at org.apache.struts.action.SecureActionServlet.process(D:/CvsPro jects/StrutsEx tTry/src/org/apache/struts/action/SecureActionServlet.java:97) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardP ipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardC ontextValve.ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardP ipeline.java:5 66) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Aut henticatorBase .java:475) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardP ipeline.java:5 64) at org.apache.catalina.valves.CertificatesValve.invoke
Re: POST request processing failure
I fixed the nasty infinite loop bug but there is still a periodic failure happening during POST's. I don't know if the failed POST's are a mod_jk bug or a problem with the remote clients HTTP POST. It happens infrequently. I just haven't had the time to try and track it down any further. What I saw was the mod_jk side kept the socket open but never completed sending the post data that was set in the content length. This left the Processor in an infinite loop trying to read from the socket. On the mod_jk side it can detect when the remote client goes away, it then closes the connection it has to Tomcat. Which would then cause the AJP Processor read to fail. Regards, Glenn Rossen Raykov wrote: I suspected that this may be related to that old issue since it disappeared after the upgrade to 4.0.4. I believe it is connected to the ajp13 protocol but I can not prove it. The strangest thing is the length of the posted request - it is always power of 1K. BW you said that you fix the Processor but how you are detecting that the connection to the httpd is closed without any changes in the C binary? As I remember in the old version of this bug there was an infinite data exchange between the httpd and Tomcat. At that time trus was reporting something like: 0.0703 recv(26, 0xFFBEE4A0, 4, 0) = 4 0xFFBEE4A0: A B\003 0.0710 recv(26, 0x0025D888, 3, 0) = 3 0x0025D888: 061FFA 0.0715 send(26, 0x0025F890, 4, 0) = 4 0x0025F890: 12 4\0\0 0.0720 recv(26, 0xFFBEE4A0, 4, 0) = 4 0xFFBEE4A0: A B\003 0.0723 recv(26, 0x0025D888, 3, 0) = 3 0x0025D888: 061FFA 0.0727 send(26, 0x0025F890, 4, 0) = 4 Was this completely because tomcat connector only? Regards, Rossen -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 11:06 AM To: Tomcat Users List Subject: Re: POST request processing failure Hah! Back many months ago the problem you are reporting would cause an infinite loop in the Processor. So I fixed the infinite loop bug and added code to report when these POST problems occur. I don't know what the source of the problem is, perhaps the remote client is aborting the connection before the POST completes? If you find out the source of the problem please let me know! Regards, Glenn Rossen Raykov wrote: I have Tomcat 4.0.4/Struts 1.0.2 with Apache 1.3.26 connected by mod_jk/1.2.0, ajp13 protocol, running on Sparc Solaris 8. The problem that I have is that from time to time there are 500 errors in my Apache log. The corresponding error on Tomcat side is: java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length A complete trace is included in the bottom of the e-mail. This only happens during POST request. According to the log it happened with many different browsers including MSIE 5 and 6 and different Netscape flavors, that's why I believe this is not a browser related issue. The logged posted data size is either 4276 or 1024 bytes and the reported time processing varies from 1 to more than 7000 seconds! I saw some similar postages but without any useful answers or comments. Is that a known/common bug and is there any solution for it? Regards, Rossen --- COMPLETE ERROR TRACE - java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length at org.apache.catalina.connector.HttpRequestBase.parseParameters( HttpRequestBas e.java:658) at org.apache.catalina.connector.HttpRequestBase.getParameterName s(HttpRequestB ase.java:723) at org.apache.catalina.connector.RequestFacade.getParameterNames( RequestFacade. java:165) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743) at org.apache.struts.action.ActionServlet.processPopulate(ActionS ervlet.java:20 61) at org.apache.struts.action.ActionServlet.process(ActionServlet.j ava:1564) at org.apache.struts.action.SecureActionServlet.process(D:/CvsPro jects/StrutsEx tTry/src/org/apache/struts/action/SecureActionServlet.java:97) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardP ipeline.java:5 66
RE: POST request processing failure
I'm not familiar how mod_jk is working. Having said that, my guess is that mod_jk is waiting to will out a buffer before to sent it to the java side. I think so because of the well aligned size reported in the log file. It may be because of incorrect length checking or something like that. I do not think it's because the client have closed it's connection since I have common errors about that and they are completely different from this one. In that case mod_jk is performing correctly and it is informing he java side about that. The problem can be because of something like loop while(content-length) but I do not have the time to check mod_jk sources :( One more time all this is a guess. The thing that bothers me is that I'm not able to reproduce the error on my one. I remember a postage explaining how one can do that but it was not working for me. If I can reproduce it most probably I'll be able to fix it also. Regards, Rossen -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 12:07 PM To: Tomcat Users List Subject: Re: POST request processing failure I fixed the nasty infinite loop bug but there is still a periodic failure happening during POST's. I don't know if the failed POST's are a mod_jk bug or a problem with the remote clients HTTP POST. It happens infrequently. I just haven't had the time to try and track it down any further. What I saw was the mod_jk side kept the socket open but never completed sending the post data that was set in the content length. This left the Processor in an infinite loop trying to read from the socket. On the mod_jk side it can detect when the remote client goes away, it then closes the connection it has to Tomcat. Which would then cause the AJP Processor read to fail. Regards, Glenn Rossen Raykov wrote: I suspected that this may be related to that old issue since it disappeared after the upgrade to 4.0.4. I believe it is connected to the ajp13 protocol but I can not prove it. The strangest thing is the length of the posted request - it is always power of 1K. BW you said that you fix the Processor but how you are detecting that the connection to the httpd is closed without any changes in the C binary? As I remember in the old version of this bug there was an infinite data exchange between the httpd and Tomcat. At that time trus was reporting something like: 0.0703 recv(26, 0xFFBEE4A0, 4, 0) = 4 0xFFBEE4A0: A B\003 0.0710 recv(26, 0x0025D888, 3, 0) = 3 0x0025D888: 061FFA 0.0715 send(26, 0x0025F890, 4, 0) = 4 0x0025F890: 12 4\0\0 0.0720 recv(26, 0xFFBEE4A0, 4, 0) = 4 0xFFBEE4A0: A B\003 0.0723 recv(26, 0x0025D888, 3, 0) = 3 0x0025D888: 061FFA 0.0727 send(26, 0x0025F890, 4, 0) = 4 Was this completely because tomcat connector only? Regards, Rossen -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 11:06 AM To: Tomcat Users List Subject: Re: POST request processing failure Hah! Back many months ago the problem you are reporting would cause an infinite loop in the Processor. So I fixed the infinite loop bug and added code to report when these POST problems occur. I don't know what the source of the problem is, perhaps the remote client is aborting the connection before the POST completes? If you find out the source of the problem please let me know! Regards, Glenn Rossen Raykov wrote: I have Tomcat 4.0.4/Struts 1.0.2 with Apache 1.3.26 connected by mod_jk/1.2.0, ajp13 protocol, running on Sparc Solaris 8. The problem that I have is that from time to time there are 500 errors in my Apache log. The corresponding error on Tomcat side is: java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length A complete trace is included in the bottom of the e-mail. This only happens during POST request. According to the log it happened with many different browsers including MSIE 5 and 6 and different Netscape flavors, that's why I believe this is not a browser related issue. The logged posted data size is either 4276 or 1024 bytes and the reported time processing varies from 1 to more than 7000 seconds! I saw some similar postages but without any useful answers or comments. Is that a known/common bug and is there any solution for it? Regards, Rossen --- COMPLETE ERROR TRACE - java.lang.RuntimeException: Read of HTTP Request POST parameters failed: read content length at org.apache.catalina.connector.HttpRequestBase.parseParameters( HttpRequestBas e.java:658
