Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 45990 invoked from network); 19 Jan 2004 13:34:16 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 19 Jan 2004 13:34:16 -0000 Received: (qmail 49712 invoked by uid 500); 19 Jan 2004 13:34:11 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 49415 invoked by uid 500); 19 Jan 2004 13:34:10 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 49399 invoked from network); 19 Jan 2004 13:34:09 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 19 Jan 2004 13:34:09 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AiZXe-0001GO-00 for ; Mon, 19 Jan 2004 14:34:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dev@cocoon.apache.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AiZXc-0001GG-00 for ; Mon, 19 Jan 2004 14:34:08 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AiZXc-0001ad-00 for ; Mon, 19 Jan 2004 14:34:08 +0100 From: Sylvain Wallez Subject: Re: No memory leak because of Recyclable! Date: Mon, 19 Jan 2004 14:34:07 +0100 Lines: 92 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: fr, en, en-us In-Reply-To: Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: >Volker Schmitt wrote: > > >>Carsten Ziegeler wrote: >> >> >>>Lars Rottmann wrote: >>> >>> >>>>>>Lars Rottmann wrote: >>>>>>Replacing the BucketMap with another Map implementation solves the >>>>>>problem of Cocoon failing at high load (where the ECM fails to look >>>>>> >>>>>> >>up >> >> >>>>>>a Selector, not the Selector looking up a handler). It does not cure >>>>>>the warning message above. >>>>>> >>>>>> >>>>>Where do you replace the BucketMap with a Map? In the ECM? >>>>>Did you try to do this replacement in the >>>>> >>>>> >>ExcaliburComponentSelector as >> >> >>>>well? >>>> >>>>I did replace every occurence of StaticBucketMap in the >>>>Excalibur-Component >>>>package with a Hashtable. >>>> >>>> >>>> >>>Ah, ok - so, it seems that the BucketMap has threading problems. >>> >>> >>Replacing >> >> >>>it with a HashMap solved the problem in the ECM. >>>But replacing the BucketMap in the ECMSelector doesn't solve the other >>>problem, as you still get the message. So, there must be another problem >>> >>> >>:) >> >> >>>I know this is obvious, but I just wanted to restate it. I think we can >>>assume that the HashMap has no threading problems. >>> >>>So, has anyone a clue? Can it be the toString() method on your operating >>>system? Hmm, I don't know. >>> >>> >>Hm we don't have this effect on our machine and we have a lot of traffic. >>The only difference in our ECM Implementation is, that I have changed >>ExcaliburComponentSelector to use the component as the key and not >>component.toString(). I changed this to use the same implementation the >>ExcaliburComponentManager use. Yes ECM uses the component as key and ECS >>use component.toString(). I wanted in our Implememtation to make sure that >>ECS work if somebody implements the toString method. >>I don't believe that this can be the problem, because then it can be no >>difference between HashTable and StaticBucketMap. >> >> >> >But there is no difference between HashTable and StaticBucketMap in the ECS and as you replaced component.toString() with component and don't have problems, perhaps it is the problem. > >Lars, can you try this and also replace every occurence of component.toString() with simply component in the ECS? > > I haven't followed all the discussion, but why is toString() used to identify components? Wouldn't it be better to use a Map keyed by the identy of the object like java.util.IdentityHashMap()? That way, we ensure there's no possible collision between two instances of the same component, and also avoid any problem related to classes redefining their own hashcode() and equals() methods. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com