Sorry guys for not jumping in earlier.
Here is some more information on how Cactus works and what it does.
Background info on the problem
------------------------------
The problem that I reported occurs when I run Cactus own suite of Test.
As you know Cactus is a testing framework. It happens that I use Cactus
tests to test Cactus itself (err ... ok so far ? :-)).
On the client side
------------------
* The HTTP connection is made using the HttpURLConnection class.
Depending on the test case, it is a GET request or a POST one (or both).
* The client side waits for a reponse from the server side (Tomcat) with
the following code :
private InputStream bufferInputStream(InputStream theInputStream)
throws IOException
{
ByteArrayOutputStream os =
new ByteArrayOutputStream(DEFAULT_CHUNK_SIZE);
copy(theInputStream, os);
ByteArrayInputStream bais =
new ByteArrayInputStream(os.toByteArray());
return bais;
}
private void copy(InputStream theInputStream, OutputStream
theOutputStream)
throws IOException
{
// Only copy if there are data to copy ... The problem is that not
// all servers return a content-length header. If there is no header
// getContentLength() returns -1. It seems to work and it seems
// that all servers that return no content-length header also do
// not block on read() operations !
if (this.delegate.getContentLength() != 0) {
byte[] buf = new byte[DEFAULT_CHUNK_SIZE];
int count;
while (-1 != (count = theInputStream.read(buf))) {
theOutputStream.write(buf, 0, count);
}
}
}
On the server side
------------------
Cactus has a servlet (called by the client side). The client side passes
information on what class and what method to call and the servlet calls
the method using reflection.
Misc ideas
----------
There are several test cases that are called before the one that fails
(testPostMethod) :
[junit] Testcase: testLongProcess took 3.745 sec
[junit] Testcase: testLotsOfData took 0.071 sec
[junit] Testcase: testReadServletOutputStream took 0.05 sec
[junit] Testcase: testPostMethod took 0.03 sec
[junit] Caused an ERROR
[junit] Connection aborted by peer: JVM_recv in socket input stream read
[junit] java.net.SocketException: Connection aborted by peer: JVM_recv
in socket input stream read
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 !
Thanks for your help, both of you(thanks Costin to jump in !).
-Vincent
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 05 February 2002 19:46
> To: Tomcat Developers List
> Subject: RE: Tomcat 3.3 - Cactus Issue
>
> On Tue, 5 Feb 2002, Larry Isaacs wrote:
>
> > I looked for this and didn't find that there was any POST data
> > sent and none was read. I certainly could have missed something.
> > I don't completely understand everything that Cactus' controller
> > servlet does on the Tomcat side. However, I think I checked to
> > see what "is.available()" was reporting, in TcpConnector, and
> > believe it was zero during Windows runs which never failed for me.
> > If extra unread characters are present, this shouldn't be
> > zero if the test succeeds. Or am I still missing something?
> > I'll try to check again.
>
> On linux, you may be able to do a tcpdump and look for ABORTs,
> that would be a good sign we're in this particular case.
>
> An intersting note is that different impl. of TCP send or
> not the ABORT - even for the same OS. I never understood
> why ( it may even be settable somewhere ) - the spec seems
> to require it.
>
> One question - with the sleep(), do you do an isAvailable()/skip()
> after the sleep ?
>
> One easy thing to check is to do a Request.getContentLength() and
> check Request.available ( it should be the length of the unread
> body ).
>
> I'll try to reproduce it and check this.
>
> Costin
>
>
>
>
>
> --
> 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]>
