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:
prio=10 tid=0x00002aab391d1000 nid=0x22a7 waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
- waiting to lock <0x00002aaac72eaf18> (a
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