You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Danno Ferrin <sh...@earthlink.net> on 2000/01/21 18:57:05 UTC
Bug Tracking (was: <%@ include ... %> bug)
This thread brings up a great process point, bug tracking. FYI, there is a category for jakarta-tomcat on the bugs.apache.org web site. And all of the committers do show up under the responsible field, and there is even one test bug listed, however I have no idea how to get on the admin end. Because many of the committers have limited bandwidth (me included since I have joined the ranks of the gainfully employed recently and am morassed in moving)
I think using a bug tracking system would be a Good Thing (tm) (used without permission) so that things don't get dropped on the floor, or that when they do we know what got dropped without having to dredge through e-mail archives. In this reguard bugs.apache is an obvious candidate for this. However we need several things...
* A bug page on jakarta that posts to bugs.apache.org but the
form is on jakarta, has the jakarta HTML visual branding,
and has categories limited to jakarta relevance.
* Some way for committers and others to listen to posted bugs.
* Instructions for committers and/or QA volunteers to update
the bug database
* Obviously committers would need to note the PR number in
patches.
I realize that the tradition is that whoever suggest the idea gets to implement it, but I have no clue how to work bullets 2 and 3. I could hack out bullet 1 and the last bullet is a committer responsibility more than anything. Does anyone else have a clue in that reguard?
--Danno
------Original Message------
From: Ryan Skow <sk...@hotsamba.com>
To: tomcat-dev@jakarta.apache.org
Sent: January 21, 2000 5:33:58 PM GMT
Subject: Re: <%@ include ... %> bug
Not exactly sure about the desired way nested includes are handled, but I wanted to re-point out that there is
also a memory leak problem with inlcudes. I posted a week or two ago about the problem, but haven't had time
to look at it. If someone else looks into the nested includes, perhaps they will run across the source of the
memory leak. I've copied my old message in here in case anyone is interested.
<OLD MESSAGE>
I have found what looks to be a memory leak with Including jsp files.
Running the standard Include example jsp page (
http://hostname/examples/jsp/include/include.jsp ) results in a
java.lang.OutOfMemoryError after being hit many times. I am currently
using IBM's Distributed Application Tester(DAT) to simulate many
simultaneous users hitting the jsp page. My DAT settings are 10 users
for 480 minutes(it doesn't actually run that long - bombs out well
before then). If any sort of load testing tool is used, you should be
able to see the memory of the JVM crawl up until it finally bombs out.
Here are the current system specs:
Solaris 2.6
tomcat-20000107 (nightly build - also tried this with the original 3.0
build)
Apache 1.3.9
256MB Ram
After doing the Include test, I then did a similar load test using the
Date example ( http://hostname/examples/jsp/dates/date.jsp ). This page
ran successfully for three days straight with the same load as specified
above.
The same set of tests was also run using JRun and Apache. No memory
leak was detected with either example JSP page.
</OLDMESSAGE>
"Robert L. Grzywinski" wrote:
> In both the 3.0 and 20000121 binary versions there is some odd behavior in
> the include directive:
>
> /index0.jsp
> /firstdir/index1.jsp
> /firstdir/include.jsp
> /firstdir/seconddir/index2.jsp
>
> include.jsp:
> <HTML>
> This is a test
> </HTML>
>
> index0.jsp:
> <%@ include file="/firstdir/index1.jsp" %>
>
> index1.jsp:
> <%@ include file="include.jsp" %>
>
> index2.jsp:
> <%@ include file="/firstdir/index1.jsp" %>
>
> Both index0.jsp and index2.jsp will fail with:
>
> org.apache.jasper.JasperException: Bad file argument to include
> at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventListener.java:671)
> at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener.java:110)
> at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:198)
> .....
>
> but index1.jsp will work. If index1.jsp looks like:
>
> index1.jsp
> <%@ include file="/firstdir/include.jsp" %>
>
> then all is well.
>
> This is a roundabout way of saying that a nested include will not use the
> path of the file that it is in, but the path of the file that included it
> if using relative paths (in nested includes). This can be shown by moving
> the include.jsp into the 'local' path of the index0.jsp and index2.jsp.
>
> Another "bug" that I found is that if the include.jsp is removed from
> the 'local' path of index0.jsp and index2.jsp the pages will continue to
> work until the server is stopped and restarted (I assume this is becuase
> the JspPage is compiled and doesn't bother to see if the file has moved).
>
> Rob Grzywinski
> rob@outlook.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Bug Tracking (was: <%@ include ... %> bug)
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
Danno and others,
Brian B is in the process of trying to get bugs.apache.org fully setup and
working. Right now it is not fully functional. I guess it is possible
to submit bug reports but it is not possible to modify existing bug
reports.
Once it is, we can update the jakarta.apache.org website and do the rest
of the stuff. In the meantime people can submit bugs anyway.
On Fri, 21 Jan 2000, Danno Ferrin wrote:
> This thread brings up a great process point, bug tracking. FYI, there is a category for jakarta-tomcat on the bugs.apache.org web site. And all of the committers do show up under the responsible field, and there is even one test bug listed, however I have no idea how to get on the admin end. Because many of the committers have limited bandwidth (me included since I have joined the ranks of the gainfully employed recently and am morassed in moving)
>
> I think using a bug tracking system would be a Good Thing (tm) (used without permission) so that things don't get dropped on the floor, or that when they do we know what got dropped without having to dredge through e-mail archives. In this reguard bugs.apache is an obvious candidate for this. However we need several things...
>
> * A bug page on jakarta that posts to bugs.apache.org but the
> form is on jakarta, has the jakarta HTML visual branding,
> and has categories limited to jakarta relevance.
>
> * Some way for committers and others to listen to posted bugs.
>
> * Instructions for committers and/or QA volunteers to update
> the bug database
>
> * Obviously committers would need to note the PR number in
> patches.
>
> I realize that the tradition is that whoever suggest the idea gets to implement it, but I have no clue how to work bullets 2 and 3. I could hack out bullet 1 and the last bullet is a committer responsibility more than anything. Does anyone else have a clue in that reguard?
>
>
> --Danno
>
>
> ------Original Message------
> From: Ryan Skow <sk...@hotsamba.com>
> To: tomcat-dev@jakarta.apache.org
> Sent: January 21, 2000 5:33:58 PM GMT
> Subject: Re: <%@ include ... %> bug
>
>
> Not exactly sure about the desired way nested includes are handled, but I wanted to re-point out that there is
> also a memory leak problem with inlcudes. I posted a week or two ago about the problem, but haven't had time
> to look at it. If someone else looks into the nested includes, perhaps they will run across the source of the
> memory leak. I've copied my old message in here in case anyone is interested.
>
> <OLD MESSAGE>
> I have found what looks to be a memory leak with Including jsp files.
> Running the standard Include example jsp page (
> http://hostname/examples/jsp/include/include.jsp ) results in a
> java.lang.OutOfMemoryError after being hit many times. I am currently
> using IBM's Distributed Application Tester(DAT) to simulate many
> simultaneous users hitting the jsp page. My DAT settings are 10 users
> for 480 minutes(it doesn't actually run that long - bombs out well
> before then). If any sort of load testing tool is used, you should be
> able to see the memory of the JVM crawl up until it finally bombs out.
> Here are the current system specs:
> Solaris 2.6
> tomcat-20000107 (nightly build - also tried this with the original 3.0
> build)
> Apache 1.3.9
> 256MB Ram
>
> After doing the Include test, I then did a similar load test using the
> Date example ( http://hostname/examples/jsp/dates/date.jsp ). This page
> ran successfully for three days straight with the same load as specified
> above.
>
> The same set of tests was also run using JRun and Apache. No memory
> leak was detected with either example JSP page.
> </OLDMESSAGE>
>
> "Robert L. Grzywinski" wrote:
>
> > In both the 3.0 and 20000121 binary versions there is some odd behavior in
> > the include directive:
> >
> > /index0.jsp
> > /firstdir/index1.jsp
> > /firstdir/include.jsp
> > /firstdir/seconddir/index2.jsp
> >
> > include.jsp:
> > <HTML>
> > This is a test
> > </HTML>
> >
> > index0.jsp:
> > <%@ include file="/firstdir/index1.jsp" %>
> >
> > index1.jsp:
> > <%@ include file="include.jsp" %>
> >
> > index2.jsp:
> > <%@ include file="/firstdir/index1.jsp" %>
> >
> > Both index0.jsp and index2.jsp will fail with:
> >
> > org.apache.jasper.JasperException: Bad file argument to include
> > at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventListener.java:671)
> > at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener.java:110)
> > at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:198)
> > .....
> >
> > but index1.jsp will work. If index1.jsp looks like:
> >
> > index1.jsp
> > <%@ include file="/firstdir/include.jsp" %>
> >
> > then all is well.
> >
> > This is a roundabout way of saying that a nested include will not use the
> > path of the file that it is in, but the path of the file that included it
> > if using relative paths (in nested includes). This can be shown by moving
> > the include.jsp into the 'local' path of the index0.jsp and index2.jsp.
> >
> > Another "bug" that I found is that if the include.jsp is removed from
> > the 'local' path of index0.jsp and index2.jsp the pages will continue to
> > work until the server is stopped and restarted (I assume this is becuase
> > the JspPage is compiled and doesn't bother to see if the file has moved).
> >
> > Rob Grzywinski
> > rob@outlook.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Peace, Anil +<:-)