Many thanks for finding this. Not suprisingly Costin's initial guess was correct. Fortunately I wasn't wrong about one assumption, which was the reason for the failure was that Tomcat 3.3 was too fast. Thanks again, to Costin.
I'll see about moving the yielding logic tonight and then tag 3.3.1-beta1 and begin staging the beta1 release. Cheers, Larry > -----Original Message----- > From: Bill Barker [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 4:38 PM > To: Tomcat Developers List > Subject: Re: Tomcat 3.3 - Cactus Issue > > > I've found an XP machine to try this on, and can pretty much > confirm that it > is an un-read POST body. The print statements show that the > bad test has > (at the end): > Content-Length: 11 > Available: 11 > > The servlet is finishing so fast that the body isn't even > available by the > time shutdownInput is called. If I modify > TcpConnection.shutdownInput to do: > socket.setSoTimeout(10); > InputStream is = socket.getInputStream(); > int available = is.available (); > if(available <= 0) { > available=1; > } > > Cactus starts working (although all of the times are > increased by 10ms). > Interestingly, Socket.shutdownInput() still causes Cactus to > fail. The > thread yielding logic needs to be moved up to before the call to > shutdownInput to get it to work. > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: "Tomcat Developers List" <[EMAIL PROTECTED]> > Sent: Thursday, February 07, 2002 9:05 AM > Subject: RE: Tomcat 3.3 - Cactus Issue > > > > On Thu, 7 Feb 2002, Vincent Massol wrote: > > > > > The particularity of testPostMethod is that it sends > information both in > > > the URL (as parameters) and in the request BODY in POST form. > > > > > > Thus, there is some POST data sent ! > > > > Ok, then what really matters is who reads the body and how. > > > > Sorry for not beeing able to spend more time on this, I wanted to > > finish the password for ajp13 ( I think it's pretty important to > > at least have the code in ). > > > > Larry - since you spent a lot of time on this, did you checked > > the values for getContentLenght() and request.available - that > > would be an easy indication of how much has been read from > > the body. > > > > Vincent - could you add a println or debug message in the method > > that is doing the POST - with the exact size of the body. > > Do you set Content-Length header ? Are you using URLConnection > > to send the body, or a custom http client. > > > > I still have a feeling something is wrong with the request > > body. All the references I found about this exception are related > > with unread data on the receiving socket - and the fact that > > it happens only sometimes and on some OSes indicates pretty > > clearly that somehow some data is still 'on the wire' when > > we close the socket ( and gets in after available() ). > > > > If the ContentLength and the read size of the body you send > > do match - then checking getContentLength() and available > > would clearly show if the servlet is indeed reading the full > > body ( and we would know that the sender is not sending more ). > > > > Would it be possible to have a difference between the 2 ? > > Like having ContentLength set to a string size, and > > some non-ascii chars in the string ? > > > > > > Costin > > > > > > -- > > 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]>
