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:[EMAIL PROTECTED] Sent: Tuesday, 2 March 2004 9:24 p.m. To: [EMAIL PROTECTED] Subject: AW: JCS Based Cache hi corin, > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Corin Moss > Gesendet: Dienstag, 2. März 2004 08:59 > An: [EMAIL PROTECTED] > 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 ================================================================
