Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 6212 invoked by uid 500); 11 Jun 2003 01:01:10 -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 6165 invoked from network); 11 Jun 2003 01:01:09 -0000 Received: from pop015pub.verizon.net (HELO pop015.verizon.net) (206.46.170.172) by daedalus.apache.org with SMTP; 11 Jun 2003 01:01:09 -0000 Received: from verizon.net ([141.156.169.148]) by pop015.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030611010117.JZGX20810.pop015.verizon.net@verizon.net> for ; Tue, 10 Jun 2003 20:01:17 -0500 Message-ID: <3EE67F5D.3050907@verizon.net> Date: Tue, 10 Jun 2003 21:01:17 -0400 From: Vadim Gritsenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Cocoon performance using MemoryStore References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [141.156.169.148] at Tue, 10 Jun 2003 20:01:17 -0500 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N volker.schmitt@basf-it-services.com wrote: >Hi, > >I changed the subject because with the old one >(org.apache.excalibur.store.impl.MRUMemoryStore) I didn't get any response >:-( >Vadim any comments? > I still had your original email in the inbox... >Volker > >Hi, > >org.apache.excalibur.store.impl.MRUMemoryStore should lookup >"Store.PERSISTENT_STORE" only if "use-persistent-cache" (m_persistent) is >true, instead you allways need to configure a persistent store if you use >MRUMemoryStore. > Sound like you are right. >MRUMemoryStore internal uses a HashMap and a LinkedList. This >implementation doesn't scale very well. My proposal is using >org.apache.commons.collections.LRUMap instead which will improve >performance. > IIRC, LRUMap is not suitable for multithreaded environment. >Some time ago Vadim has committed MRUMemoryStore into the deprecated block >of cocoon (package org.apache.cocoon.components.store). This scales much >better in multithreaded environments because the methods aren't >synchronized anymore. Internal a "org.apache.cocoon.util.MRUBucketMap" is >used. > Moreover, in addition to this, it uses twice less objects to do it's job: it combines HashMap together with List, thus it has only one internal MRUBucketMap.Entry object instead of two of them (HashMap.Entry and List.Entry) per entry. >So my question is, why don't we use this implementation, to make Cocoon >more scalable? ;-) > You can. Have you tried it yet? Vadim