tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Tomcat 3.3 - Cactus Issue
Date Thu, 07 Feb 2002 15:14:48 GMT


> -----Original Message-----
> From: Larry Isaacs [mailto:Larry.Isaacs@sas.com]
> Sent: 07 February 2002 14:16
> To: 'Tomcat Developers List'
> Subject: RE: Tomcat 3.3 - Cactus Issue
> 
> 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.
> 

On the client side,
org.apache.cactus.client.HttpClientHelper.addParametersPost()

On the server side, the POST parameters are not read by Cactus itself
(Cactus is transparent in that regards). Cactus does pass some internal
parameters (like class name, method name, etc) but always in the URL.
These are read using the
org.apache.cactus.server.ServletUtil.getQueryStringParameter()

The test cases read parameters the way they want (usually using
request.getParameter()). However, the testPostMethod() test do not read
the POST parameter.

> Does the latest 3.3.1-dev still fails on your laptop in
> spite a recent change to dump unread charecters?
> 

I've just tried with the nightly build from 6/02/2002 and it still fails
(I tried 3 times and it failed on the third try).

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




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