Re: [Resin-interest] Resin classloader leak (possibly caused by the host:default classloader)

2011-10-12 Thread Chris Pratt
Just out of curiosity, do you have a } catch(Throwable) { in your code?
 Probably in an action, or even in your ClassLoader code?

If so, if you don't } catch(ThreadDeath) { and re-throw it, you will indeed
cause a memory leak very similar to the one you describe.

Java internally uses the ThreadDeath throwable to manage internal references
between threads and their classloaders.  If they are not being propagated up
to the top, bad things will happen.
  (*Chris*)

On Wed, Oct 12, 2011 at 10:22 AM, Patric Rufflar  wrote:

> Hello everyone,
>
> it seems that resin 4.0.23 suffers from a classloader leak.
> My application's classloader is prevented from being garbage collected.
>
> Please have a look at the GC Roots of my applications classloader
> (after stopping the application and a full garbage collection):
>
> Class Name
>|  Retained Heap
>
> -
> com.caucho.env.thread.ResinThread @ 0xe27c9a60  http://*:18443-14
> Thread  |584
> '-  com.caucho.network.listen.TcpSocketLinkListener @
> 0xe0b86878  |  2.976
>'- _suspendAlarm com.caucho.util.Alarm @ 0xe279e330
> |760
>   '-  class com.caucho.util.Alarm @ 0xd03f86c0
> |480.928
>  '- _clock com.caucho.util.AlarmClock @ 0xe0aab790
> |480.720
> '- _clockArray com.caucho.util.Alarm[6] @ 0xe0ac4160
> |480.288
>'- [15927] com.caucho.util.Alarm @ 0xe8467708
> |264
>   '- _contextLoader
> com.caucho.loader.EnvironmentClassLoader @ 0xe12f7718
>|151.424
>  '- parent
> com.caucho.loader.EnvironmentClassLoader @ 0xe11fbde8
> |483.344
> '- _attributes
> java.util.concurrent.ConcurrentHashMap @ 0xe11bef38
> |392.408
>'- segments
> java.util.concurrent.ConcurrentHashMap$Segment[16] @ 0xe11bef68
> |392.336
>   '- [1]
> java.util.concurrent.ConcurrentHashMap$Segment @ 0xe11c2a40
>   |377.016
>  '- table
> java.util.concurrent.ConcurrentHashMap$HashEntry[2] @ 0xe11c2a88
>  |376.920
> '- [0]
> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xe11c2aa0
> |376.880
>'- value
> com.caucho.jsp.el.JspApplicationContextImpl @ 0xe11bbac8  |
> 376.832
>   '- _webApp
> com.caucho.server.webapp.WebApp @ 0xe12103a8 |
> 84.256
>  '- _classLoader
> com.caucho.loader.EnvironmentClassLoader @ 0xe12108c0|129.894.632
>
> --
>
>
> As you can see three EnvironmentClassLoaders are involved:
>
> 0xe12108c0, which is my application classloader (consuming 129 MB of the
> heap)
> 0xe11fbde8, which is the classloader with the id host:default
> 0xe12f7718, which is the classloader for the resin-admin application
> (which most probably is not important in this case)
>
>
> As you can see, the host:default classloader is still referencing my
> web application's classloader indirectly
> (by the entryCache_ Map, referencing to the
> com.caucho.jsp.el.JspApplicationContextImpl of my web application).
>
> What do I have to do to in order that my application classloader can
> be garbage collected?
>
> Thank you and best regards,
> Patric
>
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


[Resin-interest] Resin classloader leak (possibly caused by the host:default classloader)

2011-10-12 Thread Patric Rufflar
Hello everyone,

it seems that resin 4.0.23 suffers from a classloader leak.
My application's classloader is prevented from being garbage collected.

Please have a look at the GC Roots of my applications classloader  
(after stopping the application and a full garbage collection):

Class Name  
|  Retained Heap
-
com.caucho.env.thread.ResinThread @ 0xe27c9a60  http://*:18443-14  
Thread  |584
'-  com.caucho.network.listen.TcpSocketLinkListener @  
0xe0b86878  |  2.976
'- _suspendAlarm com.caucho.util.Alarm @ 0xe279e330 
 |760
   '-  class com.caucho.util.Alarm @ 0xd03f86c0  
 |480.928
  '- _clock com.caucho.util.AlarmClock @ 0xe0aab790 
 |480.720
 '- _clockArray com.caucho.util.Alarm[6] @ 0xe0ac4160   
 |480.288
'- [15927] com.caucho.util.Alarm @ 0xe8467708   
 |264
   '- _contextLoader  
com.caucho.loader.EnvironmentClassLoader @ 0xe12f7718   
|151.424
  '- parent  
com.caucho.loader.EnvironmentClassLoader @ 0xe11fbde8   
 |483.344
 '- _attributes  
java.util.concurrent.ConcurrentHashMap @ 0xe11bef38 
 |392.408
'- segments  
java.util.concurrent.ConcurrentHashMap$Segment[16] @ 0xe11bef68 
 |392.336
   '- [1]  
java.util.concurrent.ConcurrentHashMap$Segment @ 0xe11c2a40 
   |377.016
  '- table  
java.util.concurrent.ConcurrentHashMap$HashEntry[2] @ 0xe11c2a88
  |376.920
 '- [0]  
java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xe11c2aa0   
|376.880
'- value  
com.caucho.jsp.el.JspApplicationContextImpl @ 0xe11bbac8  | 
 376.832
   '- _webApp  
com.caucho.server.webapp.WebApp @ 0xe12103a8 |  
84.256
  '- _classLoader  
com.caucho.loader.EnvironmentClassLoader @ 0xe12108c0|129.894.632
--


As you can see three EnvironmentClassLoaders are involved:

0xe12108c0, which is my application classloader (consuming 129 MB of the heap)
0xe11fbde8, which is the classloader with the id host:default
0xe12f7718, which is the classloader for the resin-admin application  
(which most probably is not important in this case)


As you can see, the host:default classloader is still referencing my  
web application's classloader indirectly
(by the entryCache_ Map, referencing to the  
com.caucho.jsp.el.JspApplicationContextImpl of my web application).

What do I have to do to in order that my application classloader can  
be garbage collected?

Thank you and best regards,
Patric




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest