Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 21524 invoked from network); 30 Dec 2005 18:57:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Dec 2005 18:57:55 -0000 Received: (qmail 65140 invoked by uid 500); 30 Dec 2005 18:57:53 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 65107 invoked by uid 500); 30 Dec 2005 18:57:52 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 65095 invoked by uid 99); 30 Dec 2005 18:57:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Dec 2005 10:57:52 -0800 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 30 Dec 2005 10:57:52 -0800 Received: (qmail 21414 invoked from network); 30 Dec 2005 18:57:30 -0000 Received: from localhost.hyperreal.org (HELO ?127.0.0.1?) (127.0.0.1) by localhost.hyperreal.org with SMTP; 30 Dec 2005 18:57:30 -0000 Message-ID: <43B582C7.5010403@apache.org> Date: Fri, 30 Dec 2005 19:56:07 +0100 From: Carsten Ziegeler User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Cocoon 2.1.7 hang References: <43A206F9.8040808@dslextreme.com> <43A20D3F.9000402@agssa.net> <43A21018.5040901@dslextreme.com> <43AAED93.10703@dslextreme.com> <43ABAEAF.5050501@apache.org> <43ABB643.5080201@dslextreme.com> <43ABBA27.8070203@apache.org> <43ABF1BB.5010403@dslextreme.com> <43ABF858.9030807@apache.org> <43AE2F92.9060003@dslextreme.com> <43B56430.5000300@dslextreme.com> <43B58008.3050600@dslextreme.com> In-Reply-To: <43B58008.3050600@dslextreme.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Rating: localhost.hyperreal.org 1.6.2 0/1000/N X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Castor seems to have a lot of useful little "hacks" - I just found out, that we can prevent castor from checking for default constructors which I really needed for 2.2 - it's there, you only have to find out how to configure it :). Im curious how the matches configuration looks like :) Carsten Ralph Goers wrote: > 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 >> >>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 > > > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/