I don't have a direct answer to the original question but I can say
that stress tool does return cookies.
I remember running into a problem using MS web application stress tool
against TC3.2.1 and found out that MS WAST wasn't handling cookies
properly. WAST supports an older version of http cookies, where TC3.2.1
chooses a newer version. I forgot the exact version of the cookie spec.
I couldn't find how to configure the cookie header version so I changed
the code in TC3.2.1 (some interceptor) and managed to make the test run.
We had no problem with TC4 regarding that issue upto TC4.0.1. I don't
know if things changed after that.
IMHO the cookie spec is not very nice. It evolved without much thought
for backwards compatibility. The RFC I saw said it takes compatibility
into concern, but it actually depended on an arbitrary assumption
made on the 'older' implementations ("The client will skip over
anything it doesn't understand"). WAST isn't implemented that way.
Hideo.
Bill Barker wrote:
>
> Is it possible to try with:
> <%@ page session="false" %>
> (i.e. does the page actually use the session)?
>
> I'm guessing that the web stress tool isn't returning cookies, and so the
> result is that you are rapidly creating 100,000 different sessions. Tomcat
> would start to behave like you have described under these conditions.
> ----- Original Message -----
> From: "Hugh J. L." <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, February 27, 2002 6:52 PM
> Subject: more information about bug 6704 (rmi in jsp)
>
> > servlet log: empty
> > jasper log:
> > 2002-02-27 15:23:08 - JspFactoryImpl: Exception
> > initializing page context - java.lang.OutOfMemoryError
> > <<no stack trace available>>
> > this appears once just before the port becomes not
> > accessible.
> >
> > testing with web stress tool with single thread,
> > processing becomes slow and pauses for short interval
> > during the last several seconds before the port gets
> > down.
> >
> > after this problem occures, it takes longer time to
> > stop tomcat. it pauses for dozens of seconds at the
> > step of "Stop Reaper".
> >
> > the more vm memory is, the later this problem occures.
> > but in the same environment (machine, memory, vm
> > memory), the number of requests processed before port
> > gets down is almost the same each time. for example,
> > around 95,000 on my w2k and 7,000 on an old aix.
> >
> > the same servlet runs well after 4 million requests on
> > both w2k and aix.
> >
> > when we configure tomcat3.3 to use two ports and two
> > contexts pointing to the same docbase, and test only
> > one port, we can access the jsp through the other port
> > after the first port gets down.
> >
> > common jsps (not rmi client) run well on our machines,
> > tested with tens of millions requests.
> >
> > i believe our simple rmi testing code is reliable,
> > because servlet with the same rmi code runs well.
> >
> > sorry i didn't try servlet mapping, because jasper log
> > shows that it is a jsp problem.
> >
> > many thanks.
> >
--
Hideo Takahashi
Business Solutions Division, Hitachi Ltd.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
