Re: Singleton memory leak after redeploying.
Hi Rémy, It's a very good news for all !!! Until now, we used a CleanupListener to do such things, and webapps could use it or not. Now, Tomcat will do this automatically for us :-)) But I need some complements : - this new feature will be integrated in Tomcat 3 ? Tomcat 4 ? Tomcat 5.0 ? - in the clearReferences(), you put static and final fields to null; perhaps (?) this can have bad side effects on webapps ?... For example, if a thread is not stopped and envisage to do something when such static variable is null ... It's not a classic need ... but, perhaps, it is a real use case ?... - So, will it be possible to configure this new feature on such contexts ? - My webapps generally don't use commons-logging : they use log4J; so, LogFactory.release will throw an exception. No ? In advance, Thank you. Regards. On Wed, 30 Nov 2005 14:29:15 +0100 Remy Maucherat [EMAIL PROTECTED] wrote: On 11/30/05, Remy Maucherat [EMAIL PROTECTED] wrote: This issue also affects Hibernate. As it doesn't seem to be a Tomcat bug, but would be good to have a fix for, I've added possible workarounds for that (reflection code which sets as many static fields as possible to null in loaded classes when stopping the classloader) in the latest Tomcat code (which you need to get from SVN). It would need testing. To test this, recompile the class here and replace the original in catalina.jar (or put in in the appropriate folder under server/classes): http://svn.apache.org/viewcvs.cgi/*checkout*/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java?rev=348448content-type=text%2Fplain -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - 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]
Re: Singleton memory leak after redeploying.
Hi, I would like to add my two cents :-)
If I know that a class will only be instantiated once or twice, I
usually prefer to declare the logger field as non-static.
I put in this category Stateless Session EJBs, servlets, filters,
listeners, JSPs, and any singleton classes I implement by myself.
Also, on webapps, I tend to use the ServletContext as a singleton
instance container, instead of using the singleton pattern, whenever I
can. The performance is a bit worse, but it can be reduced by storing a
local reference in the classes that access them, and I gain some
benefits too: no need to manually free resources on context
undeployment, and the ability to put those classes on the common or
shared directory of Tomcat, and still have separate instances for each
webapp using them.
I usually create a simple factory class like:
class XXXFactory {
private static XXX singleton = null;
private static Object lock = new Object();
public static XXX getInstance(ServletContext ctx) {
XXX instance;
synchronized (lock) {
if (ctx == null) {
if (singleton == null) singleton = new XXX();
instance = singleton;
} else {
instance = (XXX)ctx.getAttribute(XXX.class.getName());
if (instance == null) {
instance = new XXX();
ctx.setAttribute(XXX.class.getName(), instance);
}
}
}
return instance;
}
}
Another option is to use the commons discovery framework, but sometimes
I just prefer a simpler solution. :-)
HTH,
Rodrigo Ruiz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
On 11/30/05, Remy Maucherat [EMAIL PROTECTED] wrote: This issue also affects Hibernate. As it doesn't seem to be a Tomcat bug, but would be good to have a fix for, I've added possible workarounds for that (reflection code which sets as many static fields as possible to null in loaded classes when stopping the classloader) in the latest Tomcat code (which you need to get from SVN). It would need testing. To test this, recompile the class here and replace the original in catalina.jar (or put in in the appropriate folder under server/classes): http://svn.apache.org/viewcvs.cgi/*checkout*/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java?rev=348448content-type=text%2Fplain -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
Lionel Farbos wrote: Notes : - Perhaps your Listener will have to delete other objets like SQL drivers, commons logger, ... - see also : http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 Does log4j have some nice method to free all Logger objects? It seems like a nightmare to free Loggers from all of my classes by hand... -- Mikolaj Rydzewski [EMAIL PROTECTED] Becomo S.A. tel. (12) 2927104 smime.p7s Description: S/MIME Cryptographic Signature
Re: Singleton memory leak after redeploying.
On Tue, 29 Nov 2005 00:39:51 -0600 [EMAIL PROTECTED] wrote: On Mon, Nov 28, 2005 at 06:24:52PM +0100, Lionel Farbos wrote: Hi Juan, I think your problem can't be solved (only) by Tomcat. The problem is that objets stay in memory because of pointers on static references... but aren't those supposed to go away when the classloader is no longer referenced? If you can't get to the classloader that loaded the class then you can't get to the static fields, so it should be gc'd. no? eric Sorry, I made a mistake in my tests/analysis : the singleton is freed when singleton=null; If its classloaders is not garbaged on the next Full GC this is due to another object always pointed ... So, see this : http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
On Tue, 29 Nov 2005 09:31:28 +0100 Mikolaj Rydzewski [EMAIL PROTECTED] wrote: Lionel Farbos wrote: Notes : - Perhaps your Listener will have to delete other objets like SQL drivers, commons logger, ... - see also : http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 Does log4j have some nice method to free all Logger objects? It seems like a nightmare to free Loggers from all of my classes by hand... I think it's not a good idea to have a lot of logger objects in a webapp : In a webapp, you need only one logger. Then, on the last servlet destroy, you can freed your logger with logger=null; I think no other method is needed. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Singleton memory leak after redeploying.
I disagree, only the most trivial webapp needs one logger. A web application consisting of a large number of subsystems, potentially managed/analysed by different teams should be logged to different locations. Effective debugging will come down to a well organised logging structure. -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 15:50 To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Singleton memory leak after redeploying. On Tue, 29 Nov 2005 09:31:28 +0100 Mikolaj Rydzewski [EMAIL PROTECTED] wrote: Lionel Farbos wrote: Notes : - Perhaps your Listener will have to delete other objets like SQL drivers, commons logger, ... - see also : http://opensource2.atlassian.com/confluence/spring/pages/viewpage.act ion?pageId=2669 Does log4j have some nice method to free all Logger objects? It seems like a nightmare to free Loggers from all of my classes by hand... I think it's not a good idea to have a lot of logger objects in a webapp : In a webapp, you need only one logger. Then, on the last servlet destroy, you can freed your logger with logger=null; I think no other method is needed. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLACK Disclaimer: The information contained within this e-mail is confidential and may be privileged. This email is intended solely for the named recipient only; if you are not authorised you must not disclose, copy, distribute, or retain this message or any part of it. If you have received this message in error please contact the sender at once so that we may take the appropriate action and avoid troubling you further. Any views expressed in this message are those of the individual sender. QAS Limited has the right lawfully to record, monitor and inspect messages between its employees and any third party. Your messages shall be subject to such lawful supervision as QAS Limited deems to be necessary in order to protect its information, its interests and its reputation. Whilst all efforts are made to safeguard Inbound and Outbound emails, QAS Limited cannot guarantee that attachments are virus free or compatible with your systems and does not accept any liability in respect of viruses or computer problems experienced. /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
I said this to simplify I agree that, in a large webapp, you need several loggers; each logger for a coherent system. But you have to control your loggers... In the initial question, it was like he had one logger for one class... So, the right answer should be : in log4j, there is no need for an additionnal method because, if you control your logger(s), you can freed it(them) when the servlet.destroy() is invoked. I hope it's better like this ... ;-) Regards. On Tue, 29 Nov 2005 15:54:52 - Allistair Crossley [EMAIL PROTECTED] wrote: I disagree, only the most trivial webapp needs one logger. A web application consisting of a large number of subsystems, potentially managed/analysed by different teams should be logged to different locations. Effective debugging will come down to a well organised logging structure. -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 15:50 To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Singleton memory leak after redeploying. On Tue, 29 Nov 2005 09:31:28 +0100 Mikolaj Rydzewski [EMAIL PROTECTED] wrote: Lionel Farbos wrote: Notes : - Perhaps your Listener will have to delete other objets like SQL drivers, commons logger, ... - see also : http://opensource2.atlassian.com/confluence/spring/pages/viewpage.act ion?pageId=2669 Does log4j have some nice method to free all Logger objects? It seems like a nightmare to free Loggers from all of my classes by hand... I think it's not a good idea to have a lot of logger objects in a webapp : In a webapp, you need only one logger. Then, on the last servlet destroy, you can freed your logger with logger=null; I think no other method is needed. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLACK Disclaimer: The information contained within this e-mail is confidential and may be privileged. This email is intended solely for the named recipient only; if you are not authorised you must not disclose, copy, distribute, or retain this message or any part of it. If you have received this message in error please contact the sender at once so that we may take the appropriate action and avoid troubling you further. Any views expressed in this message are those of the individual sender. QAS Limited has the right lawfully to record, monitor and inspect messages between its employees and any third party. Your messages shall be subject to such lawful supervision as QAS Limited deems to be necessary in order to protect its information, its interests and its reputation. Whilst all efforts are made to safeguard Inbound and Outbound emails, QAS Limited cannot guarantee that attachments are virus free or compatible with your systems and does not accept any liability in respect of viruses or computer problems experienced. /FONT - 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]
Re: Singleton memory leak after redeploying.
Hi Juan,
I think your problem can't be solved (only) by Tomcat.
The problem is that objets stay in memory because of pointers on static
references...
To solve this :
You can embed a CleanupListener in your webapp.
This listener seem to be like this :
package com.yourWebApp;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class CleanupListener implements ServletContextListener
{
public MyCleanupListener() { super(); }
public void contextInitialized(ServletContextEvent event) { }
public void contextDestroyed(ServletContextEvent event) {
MySingleton.delInstance();
}
}
---
Before this, you have to
1) modify your MySingleton with :
public static void delInstance()
{
if (_instance != null) { _instance._charWidths=null; }
_instance = null;
}
2) add, in web.xml :
listener
listener-classcom.yourWebApp.CleanupListener/listener-class
/listener
Notes :
- Perhaps your Listener will have to delete other objets like SQL drivers,
commons logger, ...
- see also :
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
Regards.
On Mon, 28 Nov 2005 08:29:13 +
kurrele [EMAIL PROTECTED] wrote:
Hi to everyone!! This is my first email to this list, hope is the correct
one.
I've been analyzing my code with a profiler (JProbe) because I was getting
an
OutOfMemoryException after a few redeploys of my application.
After some tests, it turned out that my static fields were not GCed after
redeploying, getting stuck with the classloader which loaded my classes.
After that, I searched the bugzilla and found
*Bug# *(Memory Leak in Classloader/Manager deploy/undeploy)*:*
20758http://issues.apache.org/bugzilla/show_bug.cgi?id=20758
where it says that the bug has been FIXED.
I tested it in Tomcat 4.1.24 and 5.0.28 getting the same result (memory leak
in static fields).
I attach here the servlet and singleton of my simple test webapp.
---
public class Test extends HttpServlet
{
MySingleton singleton = MySingleton.getInstance();
public void init(ServletConfig config) throws ServletException
{
super.init(config);
}
public void destroy()
{
singleton = null;
}
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType(text/html);
PrintWriter out = response.getWriter();
out.println(htmlheadtitleJProbe TEST
singleton/title/headbodybJProbe TEST
singleton/bBR/body/html);
out.close();
}
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException
{
processRequest(request, response);
}
protected void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException
{
processRequest(request, response);
}
}
-
public class MySingleton
{
private static MySingleton _instance = new MySingleton();
public byte[] _charWidths = new byte[1024*1024]; // 1Meg mem
allocation!!.
private MySingleton()
{}
public static MySingleton getInstance()
{
return _instance;
}
public void finalize()
{
System.out.println(!!! END-MySingleton !!!);
_instance = null;
}
}
-
After redeploying this simple webapp a 1Meg leak can be found due to
MySingleton not being GCed.
Please I want to know If I'm leaving out something, the bug is not really
fixed or I need to take another approach.
Thanks.
Juan F. S. (Spain).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
On Mon, Nov 28, 2005 at 06:24:52PM +0100, Lionel Farbos wrote: Hi Juan, I think your problem can't be solved (only) by Tomcat. The problem is that objets stay in memory because of pointers on static references... but aren't those supposed to go away when the classloader is no longer referenced? If you can't get to the classloader that loaded the class then you can't get to the static fields, so it should be gc'd. no? eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
