Hi all,

We have an application running on Resin 3.0.23.  Lately it has been  
slowing down to a crawl on a regular basis.  Thread dumps when it's  
slow show lots of threads (~30 to 100) waiting to lock the  
EnvironmentClassLoader.  Like this one:

"resin-tcp-connection-j2ee.confluence.atlassian.com:8080-843" daemon  
prio=10 tid=0x00002aab391d1000 nid=0x22a7 waiting for monitor entry  
    java.lang.Thread.State: BLOCKED (on object monitor)
         at com.caucho.loader.DynamicClassLoader.loadClass 
         - waiting to lock <0x00002aaac72eaf18> (a  
         at com.caucho.loader.DynamicClassLoader.loadClass 

The causes for loading classes are wide and varied, and they are  
succeeding.  That is, in successive thread dumps the thread locking  
the EnvironmentClassLoader changes, but many threads are still  
waiting to lock it 20 seconds later.  My belief is that the Class  
Loading is just taking way too long, and we're doing too much of it.   
While I do think the app is a bit demanding of the ClassLoader, I  
will, predictably, assure you that we haven't encountered this  
bottleneck on other App Servers (or even any other deployments to  
Resin as far as I've heard.)  Something that may be quite peculiar is  
that the app does a lot of requests to load classes that aren't  
there.  These seem to be particularly slow.

Are there any likely environmental factors that would affect the  
speed of the EnvironmentClassLoader?
Is there any way to remove the bottleneck on the EnvironmentClassLoader?

We've lately changed the GC from concurrent to parallel and increased  
the -Xmx on the app, for theoretically unrelated reasons.  There have  
been none of these lock-ups since that change.  I'd really like to  
put the -Xmx back down.  Does anybody have a compelling argument why  
having less memory would dramatically slow down Resin's class loading?


resin-interest mailing list

Reply via email to