Hi Scott and Daniel,

Thanks for the prompt replies, and sorry for my slow one.  It might  
be possible to try 3.1.5 in the future.  Currently, since we upped  
the memory and changed the collector the app is behaving extremely  
well, so I don't feel an urgent need to look into it.  We'll  
definitely take on board your advice about 3.1.5 and future versions  
having improvements to the speed and sychronisation-scope of class  
loading.  Daniel's suggestion that there may have just been too many  
garbage collections going on makes sense to me, but the GC logs don't  
really show enough GC going on to make this seem like the complete  
solution.  I hope to do some decent load testing of these settings in  
isolation in the future.

Thanks again for your advice,
Don

On 03/04/2008, at 5:07 AM, Scott Ferguson wrote:

>
> On Apr 1, 2008, at 11:26 PM, Don Willis wrote:
>
>> 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:
>
> If it's possible, can you try to reproduce this in 3.1.5?  There are a
> good number of changes to speed up the classloading, so it would be
> useful to know if it's already resolved, or if you're seeing a new
> issue.
>
> -- Scott
>
>>
>>
>> "resin-tcp-connection-j2ee.confluence.atlassian.com:8080-843" daemon
>> prio=10 tid=0x00002aab391d1000 nid=0x22a7 waiting for monitor entry
>> [0x0000000050f13000..0x0000000050f15b90]
>>    java.lang.Thread.State: BLOCKED (on object monitor)
>>         at com.caucho.loader.DynamicClassLoader.loadClass
>> (DynamicClassLoader.java:1044)
>>         - waiting to lock <0x00002aaac72eaf18> (a
>> com.caucho.loader.EnvironmentClassLoader)
>>         at com.caucho.loader.DynamicClassLoader.loadClass
>> (DynamicClassLoader.java:1021)
>>
>>
>> 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?
>>
>> Cheers,
>> Don
>>
>>
>> _______________________________________________
>> 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 mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to