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 - how to configure?
Date Tue, 02 Mar 2004 08:34:07 GMT

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

Mime
View raw message