Re: more information about bug 6704 (rmi in jsp)
yes. i tried. that is the problem. too many server session objects are created before any session expires. web stress tool's automatic cookie doesn't work well with tomcat so we don't use it in testing. i just wonder why this problem only causes port problem. when we integrate tomcat into our system, configure multi-port and multi-context for the same jsp, after one port gets down due to this problem, other ports and the entire tomcat still work well. anyway, this is not a tomcat bug. thank you, Bill. __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: more information about bug 6704 (rmi in jsp)
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. __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com -- 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]
Re: more information about bug 6704 (rmi in jsp)
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]
