Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Reply-To: <m_rolappe@web.de>
From: "Marco Rolappe" <m_rolappe@web.de>
To: <dev@cocoon.apache.org>
Subject: AW: JCS Based Cache
Date: Tue, 2 Mar 2004 09:23:37 +0100
Message-ID: <PIEGKIAINHPDEOEPIPNICECECEAA.m_rolappe@web.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <C726734B5ACA2445B2BB93E87ADD50331DB315@akxch03.tvnzad.tvnz.co.nz>
Importance: Normal
Sender: m_rolappe@web.de

hi corin,

> -----Urspr�ngliche Nachricht-----
> Von: dev-return-56510-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-56510-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Corin Moss
> Gesendet: Dienstag, 2. M�rz 2004 08:59
> An: dev@cocoon.apache.org
> Betreff: RE: JCS Based Cache
>
>
>
> You have a good point there - I'm simply going to have to replace
> the DefaultPersistentStore at my end (for testing only of course ;)
>
> One thing that has occurred to me whilst hammering the JISP based
> store, and looking at the code in a bit more depth, is that all
> of the perceived problems come as a result of the incredibly high
> iowait generated whilst accessing the store (mostly while writing
> I think.)  I notice that the AbstractReadWriteStore within the
> Excalibur components uses FIFOReadWriteLock as the lock - has
> anyone got much experience with this?  If there's a bug in there,
> it's possible that it's not relinquishing locks properly - which
> would most likely manifest in very high iowait (I theorise ;) I
> know that there are known issues with our version of JISP, but
> I'd like to be reassured first-hand that the read/write lock
> implementation we're currently using is totally robust.

I think the slow part was more due to JISP serializing out the index
(slooow) on each
writing access (remove, store, etc.).

unrelinquished locks would probably have manifested themselves in other ways
(e.g. complete lockup), but I might be wrong