commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "Logging/UndeployMemoryLeak" by SimonKitching
Date Fri, 05 Aug 2005 22:58:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak

The comment on the change is:
Add note about java.beans.Introspector

------------------------------------------------------------------------------
  that are visible to the component is the most obvious example. This causes no problems for
garbage-collecting of the component. 
  Problems come when the links become ''bidirectional'', and classes within the container
also have references to classes and objects within
  the components. The servlet and j2ee frameworks are carefully designed to avoid this where
possible; where that is unavoidable
- the container *knows* about those situations and ensures the necessary references are cleared
when a component is undeployed [1]
+ the container *knows* about those situations and ensures the necessary references are cleared
when a component is undeployed [1] [2]
  
  But if users of the container start tossing libraries that aren't designed to avoid such
references into classloaders that
  are "above" the classloader of the component and the container does not know about these
libraries then bidirectional
@@ -48, +48 @@

  
  [1] Except for the brain-dead design of JDBC where jdbc drivers loaded via a custom classloader
apparently
  get stored in a map within java.sql.!DriverManager thereby causing cyclic references to
that classloader.
+ 
+ [2] And except for the cache of classes held by the java.beans.Introspector class. In at
least some versions
+ of java, introspecting a class loaded by component's classloader causes a strong reference
to that class to be put
+ into a global cache. This means that the component's classloader is then prevented from
being unloaded. A
+ workaround is to call java.beans.Introspector.flushCaches() when the component is unloaded.
Some containers
+ may do this automatically; Apache Tomcat 5.x certainly does. In other cases, a !ServletContextListener
may need
+ to be registered to force this to be done.
  
  == Container libs are responsible for managing themselves ==
  
@@ -148, +155 @@

  model by keeping component libs inside the component will mean this problem never
  occurs.
  
- == Comment's by Ceki Gulcu ==
+ == Comments by Ceki Gulcu ==
  
  Simon, I've enjoyed reading your article. Cognizant of the memory leak
  problem you mention, the version of log4j which is currently CVS HEAD,

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


Mime
View raw message