We took some thread dumps of our product when it was running normally.
It was interesting in that we still saw in almost every stack trace the
portal calling castor which was in the class loader throwing a
ClassNotFoundException. I then stepped through the sample site and have
discovered that when
<bind-xml auto-naming="deriveByClass">
is used, Castor starts making up names and trying to load them. For
example, when a named item is specified inside a composite layout castor
takes
org.apache.cocoon.portal.layout.impl.CompositeLayoutImpl
strips off CompositeLayoutImpl and replaces it with NamedItem. It then
tries to load that class and gets a ClassNotFoundException because
NamedItem isn't in the same package. It eventually uses the correct
class name. This makes login extremely slow as every item is throwing
an exception. And, I expect, when the resource pool is exceeded the
class loader is completely overstressed and the system comes to a
grinding halt. It doesn't actually stop, but from then on it moves so
slowly that it might as well be dead.
The code in Castor suggests using the matches attribute to bypass this.
Unfortunately, there are no examples to be found on how matches could
solve this problem.
So the bottom line is, unless all your classes are in the same package
do not use deriveByClass. Or don't use Castor.
Ralph
