You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/02/27 08:56:17 UTC
DO NOT REPLY [Bug 6704] -
rmi client in jsp causes port down after large amount of requests
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6704>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6704
rmi client in jsp causes port down after large amount of requests
------- Additional Comments From william.barker@wilshire.com 2002-02-27 07:56 -------
In Tomcat 3.3.x, JSP pages are just special cases of Servlets. As such, I find
this one to be really strange. However, there isn't really enough here to let
me track it down. It would help if you could post the Tomcat log files as an
attachment to this bug.
One other thing that would be interesting to try is if you get the same problem
when you declare the servlet in the web.xml file:
<servlet>
<servlet-name>MyRMIPage</servlet-name>
<jsp-page>/rmipage.jsp</jsp-page>
</servlet>
and access it via a servlet-mapping:
<servlet-mapping>
<servlet-name>MyRMIPage</servlet-name>
<url-pattern>/MyRMIPage/*</url-pattern>
</servlet-mapping>
(The examples are instructive only, it shouldn't matter if you vary them).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: more information about bug 6704 (rmi in jsp)
Posted by "TAKAHASHI Hideo(BSD-M1G)" <hi...@bisd.hitachi.co.jp>.
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." <hu...@yahoo.com>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: more information about bug 6704 (rmi in jsp)
Posted by "Hugh J. L." <hu...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: more information about bug 6704 (rmi in jsp)
Posted by Bill Barker <wb...@wilshire.com>.
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." <hu...@yahoo.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
one more thing about bug 6704 (rmi in jsp)
Posted by "Hugh J. L." <hu...@yahoo.com>.
we test rmi jsp with microsoft web stress tool with
only one client thread.
thanks.
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
more information about bug 6704 (rmi in jsp)
Posted by "Hugh J. L." <hu...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>