I recently performed a check in one of our applications and what I found 
out was that many libraries we were using were not really "prepared" to 
be in a context that is restarted.

They usually leak resources because they are developed thiking that they 
will be used in a JVM where a restart of the application implies a 
stop/start of the JVM. For example, they create threads that cannot be 
stopped, JDBC drivers that never clean up some resources unless you use 
specific calls (so when you use them through a DataSource, they are 
never called.), bad use of ThreadLocals...

It's not that difficult to try to keep your code free of those mistakes, 
but then the libraries you use might have them.
Good luck!
D.

PD: I used YourKit Java Profiler to look for leaks.



Scott Ferguson escribió:
> On Jul 5, 2007, at 7:19 AM, Shane Cruz wrote:
> 
>> That could be related to a common classloader memory leak.  See this
>> article for more information:
>>
>> http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
> 
> That page is misleading, by the way, so I don't like it as a general  
> article.  (The description of the underlying problem is correct.)
> 
> It implies that the problem is in application code for stupidly using  
> Level.  "Perhaps it's really your fault."  In that example, it's not  
> the application's fault at all.  It's a JDK bug.  The specific  
> problem on that page is that the JDK's implementation of Level is  
> buggy.  There's no way for you to know that without someone telling  
> you, so I can't see how that's "your fault."
> 
> If you're interested in the reasons why Level is buggy, the article  
> is fine.
> 
> You'd need a profiler to track the problem down (Resin's admin  
> profiler doesn't provide enough detail for this.  jhat might work,  
> but it's a bit ugly.)
> 
> Things to check:
> 
>    1) singletons/static fields at a parent classloader (e.g. system  
> classpath or host), especially caching stuff.
> 
>    2) ThreadLocal
> 
> For example, if you put struts.jar in resin/lib, it's possible that  
> something like struts.jar has caching code that's not properly  
> classloader-aware.  If you move struts.jar into WEB-INF/lib (or resin/ 
> ext-webapp), the problem might disappear (because the cache is no  
> longer at a parent level.)
> 
> -- Scott
> 
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Jan Kriesten
>> Sent: Thursday, July 05, 2007 6:16 AM
>> To: General Discussion for the Resin application server
>> Subject: [Resin-interest] class reloading / out-of-memory
>>
>>
>> hi,
>>
>> i have the following out-of-memory error when changing a class file  
>> of a
>> web-app
>> and the web-app is re-inited:
>>
>> ---8<---
>> java.lang.OutOfMemoryError: PermGen space
>>      at java.lang.ClassLoader.defineClass1(Native Method)
>>      at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>>      at
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java: 
>> 124)
>>      at
>> com.caucho.loader.DynamicClassLoader.loadClass 
>> (DynamicClassLoader.java:1
>> 329)
>>      at
>> com.caucho.loader.DynamicClassLoader.findClass 
>> (DynamicClassLoader.java:1
>> 199)
>>      at
>> com.caucho.loader.DynamicClassLoader.loadClass 
>> (DynamicClassLoader.java:1
>> 119)
>>      at
>> com.caucho.loader.DynamicClassLoader.loadClass 
>> (DynamicClassLoader.java:1
>> 068)
>>      at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>> ---8<---
>>
>> this regularly happens after the app is reloaded for the 5th or 6th
>> time.
>>
>> the admin service works without a flaw and indicates that there should
>> be enough
>> free memory:
>>
>> Total memory:        122.42Meg
>> Free memory: 56.45Meg
>>
>> any hints where to look?
>>
>> i'm using resin 3.1.1 and jdk 1.6
>>
>> best regards, --- jan.



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

Reply via email to