Hey thanks guys ! You're too fast for me ... I'm trying to catch up with
the emails ... I was just answering a previous email from Costin and you
come up with the result !
Just to let me understand what you're saying ...
Are you saying that the logic in Tomcat is that prior to closing a
socket, all data is read first ?
And that this is not what is happening here ?
And thus if I changed my test case to explicitly tell Tomcat to read the
body (using request.getParameter("xxx")) the problem will disappear ?
Could it be because for this test case (testPostMethod) HTTP parameters
are sent both in the URL _and_ in the body as POST data ?
Thanks a lot
-Vincent
> -----Original Message-----
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: 07 February 2002 21:38
> 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:tomcat-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:tomcat-dev-
> [EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
