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) > >>> 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(Certificat > >>esValve.java:2 > >> > >>>46) > >>> at > >>> > >> > >>org.apache.catalina.core.StandardPipeline.invokeNext(StandardP > >>ipeline.java:5 > >> > >>>64) > >>> 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.StandardContext.invoke(StandardContex > >>t.java:2347) > >> > >>> at > >>> > >> > >>org.apache.catalina.core.StandardHostValve.invoke(StandardHost > >>Valve.java:180 > >> > >>>) > >>> at > >>> > >> > >>org.apache.catalina.core.StandardPipeline.invokeNext(StandardP > >>ipeline.java:5 > >> > >>>66) > >>> at > >>> > >> > >>org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDi > >>spatcherValve. > >> > >>>java:170) > >>> at > >>> > >> > >>org.apache.catalina.core.StandardPipeline.invokeNext(StandardP > >>ipeline.java:5 > >> > >>>64) > >>> at > >>> > >> > >>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport > >>Valve.java:170 > >> > >>>) > >>> at > >>> > >> > >>org.apache.catalina.core.StandardPipeline.invokeNext(StandardP > >>ipeline.java:5 > >> > >>>64) > >>> at > >>> > >> > >>org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValv > >>e.java:468) > >> > >>> at > >>> > >> > >>org.apache.catalina.core.StandardPipeline.invokeNext(StandardP > >>ipeline.java:5 > >> > >>>64) > >>> 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.StandardEngineValve.invoke(StandardEn > >>gineValve.java > >> > >>>:174) > >>> 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.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor > .java:458) > >> > >>> at > >>>org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) > >>> at java.lang.Thread.run(Thread.java:536) > >>> > >>>--- > >>>Rossen Raykov > >>>COGNICASE U.S.A. Inc. > >>>(908) 860-1100 Ext. 1140 > >>>[EMAIL PROTECTED] > >>> > >>>-- > >>>To unsubscribe, e-mail: > >> > >><mailto:[EMAIL PROTECTED]> > >> > >>>For additional commands, e-mail: > >> > >><mailto:[EMAIL PROTECTED]> > >> > >> > >> > >> > >>-- > >>To unsubscribe, e-mail: > >><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > >><mailto:[EMAIL PROTECTED]> > >> > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
