You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Corin Moss <Co...@tvnz.co.nz> on 2004/03/02 09:34:07 UTC

RE: JCS Based Cache - how to configure?

Hi Guys,

The more I look at JCS, the more interesting it gets.  The simplest way to use it is to simply instantiate a JCS object, and configure it using a "cache configuration file" - obviously then the JCS object would be wrapped appropriately.

If we were to use JCS at its most generic level then the user could easily use any member store they wanted simply by configuring properly.  The only problem I really have is the nature of the configuration.  It is essentially a properties file.  Obviously this should be done within the cocoon xconf - not an external file.  How have you handled this in the past?  Are there any examples I can look at which do something similar?

Sorry about the volume of mail - this problem has really caught my interest :)

Thanks,

Corin

-----Original Message-----
From: Corin Moss
Sent: Tuesday, 2 March 2004 8:59 p.m.
To: dev@cocoon.apache.org
Subject: 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.

JCS does have its own R/W lock of course - but I'd love not to have to change too many classes ;)

Cool,

Corin

-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]

Sent: Tuesday, 2 March 2004 8:45 p.m.
To: dev@cocoon.apache.org
Subject: Re: JCS Based Cache


Le Mardi, 2 mars 2004, à 08:16 Europe/Zurich, Corin Moss a écrit :

> ... I guess conceptually this really belongs within the
> Avalon-Excalibur-store framework, as it will sit along side

> AbstractJispFilesystemStore rather than on top of it...

Makes sense but I don't think it prevents you from implementing a Store

in the Cocoon source tree for now, like the (broken AFAIK)

org.apache.cocoon.components.store.impl.FilesystemStore which simply

extends AbstractFilesystemStore.

It can always be moved to Avalon later on if needed, but it might be

easier to work on it "here" for now.

What I don't see is how you can configure a different Store than the

DefaultPersistentStore, have you figured this out already? Cocoon uses

DefaultPersistentStore by default but I didn't find where this is

defined.

-Bertrand

================================================================
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 ================================================================

================================================================
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
================================================================