cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Cocoon 2.1.7 hang
Date Fri, 30 Dec 2005 16:45:36 GMT
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

Mime
View raw message