For the testPostMethod test, can you point me to where in Cactus, the POST data is added/generated and where in the server side code it is read.
Does the latest 3.3.1-dev still fails on your laptop in spite a recent change to dump unread charecters? Thanks. Larry > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 8:09 AM > To: 'Tomcat Developers List' > Subject: RE: Tomcat 3.3 - Cactus Issue > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
