Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 48446 invoked by uid 500); 22 Aug 2001 09:23:13 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 48425 invoked from network); 22 Aug 2001 09:23:12 -0000 Message-ID: <3B8379D7.9000507@anyware-tech.com> Date: Wed, 22 Aug 2001 11:22:31 +0200 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: fr,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [C2] Re: LoadTest References: <7595.998467697@www56.gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Gerhard Froehlich wrote: > Hi, > ok here is a blind shot. Yesterday I traced instance creation > of cocoon with OptimizeIt (See my posting last night). There > was one conspicuousness. The java.util.HashMap class had > 19505 instances open by 20 threads fireing against cocoon2. > > This instances weren't freed by the gc, because they have all one > reference to the generated class BrowserImpl.java in line 175 still > open. This effect only occurs on heavy load. > > When you fireing 40 threads against cocoon, the instances double. > > Cheers > Gerhard BrowserImpl methods only rely on data set up during configure(). So I made it ThreadSafe (and also replaced Vector by ArrayList). It will certainly not solve all problems, but should reduce HashMap allocation you mentioned. Sylvain. -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org