Thanks for the clarification. This seems reasonable, as I thought it would be unlikely in most circumstances. Not properly closing/de-referencing external resources, including threads would cause the JVM's memory to grow. JDBC resources would probably be the most common.
Oscar http://daydream.stanford.edu/tomcat/install_web_services.html On Wed, 17 Dec 2003, Shapira, Yoav wrote: > > Howdy, > Sure, here's one example: > > void someMethod() { > // MyJob implements Runnable > Thread myJobThread = new Thread(new MyJob()); > > boolean goAhead = evaluateSomeCondition(); > if(goAhead) { > myJobThread.start(); > } else { > System.out.println("Not running job."); > } > } > > Because creating a thread allocates some resources and adds a reference > to the thread in its parent ThreadGroup, when the method is done the > Thread cannot be garbage-collected even though the myJobThread reference > is gone. A simple fix might be to do the thread creation inside the > goAhead clause. > > This is only to show it's possible. Obviously this is not an example of > good practice, but it's an easy enough mistake to make ;) The above is > an implementation of an example mentioned on this thread: > http://forum.java.sun.com/thread.jsp?forum=4&thread=456545&message=20839 > 57. There are others... > > Yoav Shapira > Millennium ChemInformatics > > > >-----Original Message----- > >From: Oscar Carrillo [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, December 17, 2003 2:38 PM > >To: Tomcat Users List > >Subject: RE: Need some Tomcat Configuration help badly > > > >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:[EMAIL PROTECTED] > >> >> >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: > [EMAIL PROTECTED] > >> >> >For additional commands, e-mail: > [EMAIL PROTECTED] > >> >> > >> >> > >> >> > >> >> > >> >> 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: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> >> > >> > > >> > > >> > >--------------------------------------------------------------------- > >> >To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > >> 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
