Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 82333 invoked from network); 2 Apr 2010 03:34:25 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Apr 2010 03:34:25 -0000 Received: (qmail 30049 invoked by uid 500); 2 Apr 2010 03:34:25 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 30028 invoked by uid 500); 2 Apr 2010 03:34:25 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 30021 invoked by uid 99); 2 Apr 2010 03:34:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 03:34:24 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.92.149] (HELO qw-out-1920.google.com) (74.125.92.149) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 03:34:20 +0000 Received: by qw-out-1920.google.com with SMTP id 4so681789qwk.60 for ; Thu, 01 Apr 2010 20:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.10 with HTTP; Thu, 1 Apr 2010 20:33:57 -0700 (PDT) Date: Thu, 1 Apr 2010 21:33:57 -0600 Received: by 10.229.193.18 with SMTP id ds18mr2651956qcb.14.1270179237423; Thu, 01 Apr 2010 20:33:57 -0700 (PDT) Message-ID: Subject: ClassInfo.CLASS_INFO_MAP From: Derek Scherger To: user-java@ibatis.apache.org Content-Type: multipart/alternative; boundary=0016362845f43f6b7c048338a6a0 --0016362845f43f6b7c048338a6a0 Content-Type: text/plain; charset=UTF-8 I ran into an "interesting" issue with sqlmaps today. I've been trying to get a webapp into a state where it can be reloaded repeatedly without eventually failing but this turns out to be almost impossible (see http://www.szegedi.org/articles/memleak.html for an entertaining write up). The JDK has various places that can hold references to classes loaded by a webapp classloader, which prevents the webapp classloader from being garbage collected (see http://www.docjar.com/docs/api/sun/net/www/http/HttpClient.html and http://www.docjar.com/html/api/sun/net/www/http/KeepAliveCache.java.html for examples). Eventually the (Sun) JVM runs out of PermGen space, throws an OutOfMemoryError and all is lost. Tomcat 5.5 tries to clean up various things in the clearReferences method of its WebappClassLoader, like deregistering jdbc drivers, clearing various IntrospectionUtils caches, releasing the commons logging LogFactory, etc. but there are so many different things that hold references it is fighting a losing battle. In trying to rearrange various jars in the app I'm working with to avoid holding references from outside the webapp classloader to classes inside the webapp classloader I noticed that sqlmaps has similar issues. The ClassInfo CLASS_INFO_MAP holds onto a static map keyed by class. If the sqlmap jars are loaded from outside the webapp classloader (in Tomcat's common or shared libs) this map can hold references to classes loaded by the webapp classloader. These references keep the webapp classloader live in the eye of the garbage collector and it will never be reclaimed. This keeps all the classes loaded by the webapp classloader live and eats up PermGen space fairly quickly. Here's another good link that notes problems with sqlmaps as well http://www.java-community.de/archives/140-Memory-leaks-et-alii.html There are so many other places that do similar things that fixing sqlmaps probably won't help the situation much, but it sure can't hurt. It would be nice if sqlmaps could be changed to use weak references to the cached reflection information so that it isn't the reason a webapp classloader can't be reclaimed by the garbage collector. Cheers, Derek --0016362845f43f6b7c048338a6a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I ran into an "interesting" issue with sqlmaps today.

I've been trying to get a webapp into a state where it can be r= eloaded repeatedly without eventually failing but this turns out to be almo= st impossible (see http://www.szegedi.org/articles/memleak.html for an = entertaining write up). The JDK has various places that can hold references= to classes loaded by a webapp classloader, which prevents the webapp class= loader from being garbage collected (see http://www.docj= ar.com/docs/api/sun/net/www/http/HttpClient.html and http://www.docjar.com/html/api/sun/net/www/http/KeepAliveCache.= java.html for examples). Eventually the (Sun) JVM runs out of PermGen s= pace, throws an OutOfMemoryError and all is lost.

Tomcat 5.5 tries to clean up various things in the clea= rReferences method of its WebappClassLoader, like deregistering jdbc driver= s, clearing various IntrospectionUtils caches, releasing the commons loggin= g LogFactory, etc. but there are so many different things that hold referen= ces it is fighting a losing battle.

In trying to rearrange various jars in the app I'm = working with to avoid holding references from outside the webapp classloade= r to classes inside the webapp classloader I noticed that sqlmaps has simil= ar issues. The ClassInfo CLASS_INFO_MAP holds onto a static map keyed by cl= ass. If the sqlmap jars are loaded from outside the webapp classloader (in = Tomcat's common or shared libs) this map can hold references to classes= loaded by the webapp classloader. These references keep the webapp classlo= ader live in the eye of the garbage collector and it will never be reclaime= d. This keeps all the classes loaded by the webapp classloader live and eat= s up PermGen space fairly quickly.

Here's another good link that notes problems with s= qlmaps as well=C2=A0http://www.java-community.de/arc= hives/140-Memory-leaks-et-alii.html

There are so many other places that do similar things t= hat fixing sqlmaps probably won't help the situation much, but it sure = can't hurt. It would be nice if sqlmaps could be changed to use weak re= ferences to the cached reflection information so that it isn't the reas= on a webapp classloader can't be reclaimed by the garbage collector.

Cheers,
Derek

--0016362845f43f6b7c048338a6a0--