Re: Singleton memory leak after redeploying.

[Lionel Farbos]

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=348448&content-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.

[Remy Maucherat]

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=348448&content-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.

[Remy Maucherat]

On 11/28/05, 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)*:*
> 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("JProbe TEST
> singletonJProbe TEST
> singleton");
> 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.

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.

--
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.

[Rodrigo Ruiz]

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.

[Lionel Farbos]

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]
> 
> 
> 
> 
>  
> ---
> QAS Ltd.
> Registered in England: No 2582055
> Registered in Australia: No 082 851 474
> ---
>   
> 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.
> 
> 
> 
> -
> 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.

[Allistair Crossley]

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]




 
---
QAS Ltd.
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
  
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.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Singleton memory leak after redeploying.

[Lionel Farbos]

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.

[Lionel Farbos]

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.

[Mikolaj Rydzewski]

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.

[erh]

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]

Re: Singleton memory leak after redeploying.

[Lionel Farbos]

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 :

  com.yourWebApp.CleanupListener


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)*:*
> 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("JProbe TEST
> singletonJProbe TEST
> singleton");
> 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]