cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: JCS Based Cache - how to configure?
Date Tue, 02 Mar 2004 08:41:42 GMT
I think the first solution to see how JCS behaves is to
stick to the properties file. 
If JCS can be configured differently than you could make
the component Parameterizable. 

Carsten 

> -----Original Message-----
> From: Corin Moss [mailto:Corin.Moss@tvnz.co.nz] 
> Sent: Tuesday, March 02, 2004 9:34 AM
> To: dev@cocoon.apache.org
> Subject: 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 
> ================================================================
> 


Mime
View raw message