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 18:44:24 GMT
OK. I figured out how to use the matches attribute and was able to 
verify that it doesn't throw ClassNotFoundExceptions all the time.  I'll 
do a little load testing next to see what kind of difference it makes on 
throughput.

Ralph Goers wrote:

> 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