tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Tomcat 3.3 - Cactus Issue
Date Thu, 07 Feb 2002 21:57:41 GMT
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:wbarker@wilshire.com]
> 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: <costinm@covalent.net>
> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
> 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:tomcat-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:tomcat-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-
> help@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message