cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corin Moss" <Corin.M...@tvnz.co.nz>
Subject RE: JCS Based Cache
Date Tue, 02 Mar 2004 08:30:39 GMT

Hiya :)

I don't think you're wrong at all - I totally agree with you.  The interesting thing is that
total lockup is what I experience at times :) iowaits approaching 99.9% when we do really
heavy load testing (or sometimes even under particularly heavy "normal" usage.) 

On the bright side, JCS has this very interesting implementation:

http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html

My initial concern was persistence, but given a clean shutdown the indices are written to
disk :)

I think I'm becoming a bit of a JCS zealot - better be careful!! :)

-----Original Message-----
From: Marco Rolappe [mailto:m_rolappe@web.de]
Sent: Tuesday, 2 March 2004 9:24 p.m.
To: dev@cocoon.apache.org
Subject: AW: JCS Based Cache


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



================================================================
CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

================================================================
For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz
================================================================

Mime
View raw message