tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: Tomcat 3.3 - Cactus Issue
Date Tue, 05 Feb 2002 19:08:22 GMT
On Tue, 5 Feb 2002 costinm@covalent.net wrote:

> Most of the time it happens when something is still in the write
> buffer ( i.e. unsent or unread ), and the remote side is closing
> the connection.

I'll try again:

Assuming CLIENT sending data to SERVER. The exception happens when:
 - server has received some data from client ( so client believes
the data reached the destionation ). The data is in some OS buffer.

 - server dies or close() the socket, without reading the data from
the OS buffer

 - some OSes have a TCP implementation that does what I believe to
be right - send an ABORT ( instead of the regular CLOSE ).

 - the client will receive the ABORT and throw the exception
( that coresponds to SIGPIPE if the same thing would be done
locally )


( it seems my original mail was not very clear ).

My feeling is that we are exaclty in this case - the logic
to close the socket is trying to read the remaining data from
the available() buffer ( impl. of the fix for extra CRLF bug ),
but the impl is likely to fail on a fast OS or on certain
threading models where the CLIENT may send aditional data
between we read the input buffer and close().


Vincent: is your test servlet reading the body i.e. calls
getParameters() if it's a url-encoded body, or read
the full stream ?

If not, I believe the current behavior is correct and shouldn't
be changed - it signals the CLIENT that whatever it posted
was not read, and that's a very usefull information we shouldn't
hide.

If this is not the case, and the servlet has read the body -
than it's a serious problem.

Costin


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