tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <Larry.Isa...@sas.com>
Subject RE: Tomcat 3.3 - Cactus Issue
Date Thu, 07 Feb 2002 14:15:36 GMT
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:vmassol@octo.com]
> 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: costinm@covalent.net [mailto:costinm@covalent.net]
> > 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-
> > 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