tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Tomcat 3.3 - Cactus Issue
Date Thu, 07 Feb 2002 22:32:47 GMT
See inline.
----- Original Message -----
From: "Vincent Massol" <vmassol@octo.com>
To: "'Tomcat Developers List'" <tomcat-dev@jakarta.apache.org>
Sent: Thursday, February 07, 2002 1:57 PM
Subject: RE: Tomcat 3.3 - Cactus Issue


> 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 ?
Yes, provided that it can be read without blocking (which isn't the case
here).
>
> And that this is not what is happening here ?
The Client is finishing before the body has arrived.
>
> And thus if I changed my test case to explicitly tell Tomcat to read the
> body (using request.getParameter("xxx")) the problem will disappear ?
Correct.  Then Tomcat will read the body (blocking until it comes).
>
> 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>
>


--
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