From dev-return-56519-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Mar 02 08:40:09 2004 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 44050 invoked from network); 2 Mar 2004 08:40:08 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Mar 2004 08:40:08 -0000 Received: (qmail 93799 invoked by uid 500); 2 Mar 2004 08:39:34 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 93722 invoked by uid 500); 2 Mar 2004 08:39:33 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 93683 invoked from network); 2 Mar 2004 08:39:32 -0000 Received: from unknown (HELO mail.s-und-n.de) (212.8.217.2) by daedalus.apache.org with SMTP; 2 Mar 2004 08:39:32 -0000 Received: from notes.sundn.de (ntsrv5.sundn.de [10.10.2.10]) by mail.s-und-n.de (postfix) with ESMTP id CDB6719F623 for ; Tue, 2 Mar 2004 09:39:44 +0100 (CET) Received: from hw0386 ([10.10.2.54]) by notes.sundn.de (Lotus Domino Release 6.5) with ESMTP id 2004030209343143-65650 ; Tue, 2 Mar 2004 09:34:31 +0100 From: "Carsten Ziegeler" To: Subject: RE: JCS Based Cache - how to configure? Date: Tue, 2 Mar 2004 09:41:42 +0100 Organization: S&N AG MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQAMIrHMB9ymULhSbuuBxwQnBra1AAAVADw X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 6.5|September 26, 2003) at 02.03.2004 09:34:31, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 6.5|September 26, 2003) at 02.03.2004 09:34:32, Serialize complete at 02.03.2004 09:34:32 Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I think the first solution to see how JCS behaves is to stick to the properties file.=20 If JCS can be configured differently than you could make the component Parameterizable.=20 Carsten=20 > -----Original Message----- > From: Corin Moss [mailto:Corin.Moss@tvnz.co.nz]=20 > Sent: Tuesday, March 02, 2004 9:34 AM > To: dev@cocoon.apache.org > Subject: RE: JCS Based Cache - how to configure? >=20 >=20 > Hi Guys, >=20 > The more I look at JCS, the more interesting it gets. The=20 > simplest way to use it is to simply instantiate a JCS object,=20 > and configure it using a "cache configuration file" -=20 > obviously then the JCS object would be wrapped appropriately. >=20 > If we were to use JCS at its most generic level then the user=20 > could easily use any member store they wanted simply by=20 > configuring properly. The only problem I really have is the=20 > nature of the configuration. It is essentially a properties=20 > file. Obviously this should be done within the cocoon xconf=20 > - not an external file. How have you handled this in the=20 > past? Are there any examples I can look at which do=20 > something similar? >=20 > Sorry about the volume of mail - this problem has really=20 > caught my interest :) >=20 > Thanks, >=20 > Corin >=20 > -----Original Message----- > From: Corin Moss >=20 > Sent: Tuesday, 2 March 2004 8:59 p.m. > To: dev@cocoon.apache.org > Subject: RE: JCS Based Cache >=20 >=20 >=20 > You have a good point there - I'm simply going to have to=20 > replace the DefaultPersistentStore at my end (for testing=20 > only of course ;) >=20 > One thing that has occurred to me whilst hammering the JISP=20 > based store, and looking at the code in a bit more depth, is=20 > that all of the perceived problems come as a result of the=20 > incredibly high iowait generated whilst accessing the store=20 > (mostly while writing I think.) I notice that the=20 > AbstractReadWriteStore within the Excalibur components uses=20 > FIFOReadWriteLock as the lock - has anyone got much=20 > experience with this? If there's a bug in there, it's=20 > possible that it's not relinquishing locks properly - which=20 > would most likely manifest in very high iowait (I theorise ;)=20 > I know that there are known issues with our version of JISP,=20 > but I'd like to be reassured first-hand that the read/write=20 > lock implementation we're currently using is totally robust. >=20 > JCS does have its own R/W lock of course - but I'd love not=20 > to have to change too many classes ;) >=20 > Cool, >=20 > Corin >=20 > -----Original Message----- > From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org] >=20 > Sent: Tuesday, 2 March 2004 8:45 p.m. > To: dev@cocoon.apache.org > Subject: Re: JCS Based Cache >=20 >=20 > Le Mardi, 2 mars 2004, =E0 08:16 Europe/Zurich, Corin Moss a =E9crit : >=20 > > ... I guess conceptually this really belongs within the >=20 > > Avalon-Excalibur-store framework, as it will sit along side >=20 > > AbstractJispFilesystemStore rather than on top of it... >=20 > Makes sense but I don't think it prevents you from=20 > implementing a Store >=20 > in the Cocoon source tree for now, like the (broken AFAIK) >=20 > org.apache.cocoon.components.store.impl.FilesystemStore which simply >=20 > extends AbstractFilesystemStore. >=20 > It can always be moved to Avalon later on if needed, but it might be >=20 > easier to work on it "here" for now. >=20 > What I don't see is how you can configure a different Store than the >=20 > DefaultPersistentStore, have you figured this out already? Cocoon uses >=20 > DefaultPersistentStore by default but I didn't find where this is >=20 > defined. >=20 > -Bertrand >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CAUTION: This e-mail and any attachment(s) contains=20 > information that is intended to be read only by the named=20 > recipient(s). It may contain information that is=20 > confidential, proprietary or the subject of legal privilege.=20 > This information is not to be used by any other person and/or=20 > organisation. If you are not the intended recipient, please=20 > advise us immediately and delete this e-mail from your=20 > system. Do not use any information contained in it. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For more information on the Television New Zealand Group,=20 > visit us online at http://www.tvnz.co.nz=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CAUTION: This e-mail and any attachment(s) contains=20 > information that is intended to be read only by the named=20 > recipient(s). It may contain information that is=20 > confidential, proprietary or the subject of legal privilege.=20 > This information is not to be used by any other person and/or=20 > organisation. If you are not the intended recipient, please=20 > advise us immediately and delete this e-mail from your=20 > system. Do not use any information contained in it. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For more information on the Television New Zealand Group,=20 > visit us online at http://www.tvnz.co.nz=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20