Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Date: Wed, 17 Dec 2003 11:38:29 -0800 (PST)
From: Oscar Carrillo <tomcat@daydream.stanford.edu>
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
Subject: RE: Need some Tomcat Configuration help badly
In-Reply-To: <9C5166762F311146951505C6790A9CF8013DF8CF@US-VS1.corp.mpi.com>
Message-ID: <Pine.LNX.4.44.0312171133410.32429-100000@daydream.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Thanks.

I'm still not sure what kind of code would produce a memory leak. Any 
chance you could give a brief description or example of this?

Thanks,
Oscar
http://daydream.stanford.edu/tomcat/install_web_services.html

On Wed, 17 Dec 2003, Shapira, Yoav wrote:

> 
> Howdy,
> 
> >If I understand this correctly, there are references lying around that
> >point to objects that no longer are needed. Is this something the
> >developer does or something tomcat does in compiling the servlets?
> 
> This is something the developer does.
> 
> >In other words, is there something the developer or administrator can
> do
> >to avoid this? Does pre-compiling the jsp files avoid this?
> 
> Pre-compiling JSP files helps avoid the javac memory leak previously
> described.  The memory leak is just inside the JSPC process, not inside
> the tomcat running server.
> 
> The developer can employ good coding practices as well as good QA
> practices such as the use of a profiler throughout the lifecycle of the
> project to detect and prevent memory leaks.
> 
> >If you don't change the JSP pages, or class files, then the memory leak
> >that is created just happens once. In this scenario, the memory
> >leak wouldn't keep growing until eventually tomcat does. Is that
> correct?
> 
> This is true.  In this scenario (one compilation of each JSP in a
> running tomcat server) you'd have a limited memory leak per JSP.  If you
> have thousands of JSPs, this can still be a serious leak.
> 
> Yoav Shapira
> 
> >
> >Thanks,
> >Oscar
> >http://daydream.stanford.edu/tomcat/install_web_services.html
> >
> >On Wed, 17 Dec 2003, Shapira, Yoav wrote:
> >
> >>
> >> Howdy,
> >> Actually, the popularity and usage of Jikes has been decreasing (at
> >> least as measured by downloads).  Javac's memory-handling behavior
> has
> >> been improved significantly.
> >>
> >> The memory leaks described earlier in this thread are not
> >> compiler-related and simply swapping compilers would not help.  They
> are
> >> problems of reference scope.
> >>
> >> Yoav Shapira
> >> Millennium ChemInformatics
> >>
> >>
> >> >-----Original Message-----
> >> >From: Nikola Milutinovic [mailto:Nikola.Milutinovic@ev.co.yu]
> >> >Sent: Monday, December 15, 2003 1:16 AM
> >> >To: Tomcat Users List
> >> >Subject: Re: Need some Tomcat Configuration help badly
> >> >
> >> >Dick Steflik wrote:
> >> >
> >> >> I had the same question. In all of the years I've worked with Java
> >> I've
> >> >> always thought  it was free of memory leaks. If you use a
> different
> >> >> compiler does the problem go away. Is that how people like JRun
> >> >> (Macromedia)  and WebSphere (IBM) avoid the problem?
> >> >
> >> >It could be. Someone here mentioned using Jikes for Tomcat as a
> >> workaround
> >> >(solution). I know that Jikes has bugs, here and there, but it can
> be
> >> made
> >> >to
> >> >work and it comes with Tomcat. Considering that "javac" has an all
> >> present
> >> >bug
> >> >(this memory leak), Jikes is better. I guess commercial solutions
> use
> >> their
> >> >own
> >> >implementations or fork off to get rid of memory leak.
> >> >
> >> >Why does JavaC have that memory leak?
> >> >
> >> >Nix.
> >> >
> >> >
> >>
> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >> This e-mail, including any attachments, is a confidential business
> >communication, and may contain information that is confidential,
> >proprietary and/or privileged.  This e-mail is intended only for the
> >individual(s) to whom it is addressed, and may not be saved, copied,
> >printed, disclosed or used by anyone else.  If you are not the(an)
> intended
> >recipient, please immediately delete this e-mail from your computer
> system
> >and notify the sender.  Thank you.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> 
> 
> This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org