jakarta-jcs-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: Store surviving a shutdown
Date Wed, 19 May 2004 06:38:46 GMT
Gosh, thanks Travis, you're right. My test case did wrote the data
with a different class than it has been read with. Argh! Sorry!

I will try it again and have a look where the problem really lies.

Carsten

> -----Original Message-----
> From: Travis Savo [mailto:tsavo@IFILM.com] 
> Sent: Tuesday, May 18, 2004 11:02 PM
> To: 'Turbine JCS Developers List'
> Subject: RE: Store surviving a shutdown
> 
> That would happen when the LRUMapJCS was written to disk, and 
> then the LRUMapJCS class file changed. Presently there's no 
> good solution for migrating from older versions of classes to 
> new ones with straight Java Object Serialization.
> 
> My suggestion would be to delete your disk cache, as this 
> will force the new version of the class to be written out to 
> disk. You'll need to do this any time your LRUMapJCS class 
> changes (or any classes being serialized to disk for that matter).
> 
> If class migration is a requirement (i.e. you need to be able 
> to upgrade your JCS with LRUMapJCS changes without loosing 
> your disk cache), you might want to look into some of the 
> Java XML Serialization frameworks available, as I seem to 
> have a vague memory of one of them supporting class migration.
> It would be fairly trivial to create a new disk cache which 
> used it instead.
> 
> -Travis Savo
> 
> 
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Tuesday, May 18, 2004 1:46 PM
> To: 'Turbine JCS Developers List'
> Subject: RE: Store surviving a shutdown
> 
> 
> I think I found the problem now:
> 
> During reading the keys the following exception occurs in 
> readObject in
> IndexedDisk:
> 
> ClassCastException: local class incompatible: stream 
> classdesc serialVersionUID = 7888269624850553887, local class 
> serialVersionUID =
> 776964015449842672
> 
> And classname is org.apache.jcs.auxiliary.disk.LRUMapJCS
> 
> Hmm...
> 
> Carsten 
> 
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > Sent: Tuesday, May 18, 2004 4:15 PM
> > To: 'Turbine JCS Developers List'
> > Subject: RE: Store surviving a shutdown
> > 
> > Hi,
> > 
> > to complete the picture, attached is the configuration we use.
> > 
> > Carsten
> > 
> > > -----Original Message-----
> > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > > Sent: Tuesday, May 18, 2004 2:31 PM
> > > To: 'Turbine JCS Developers List'
> > > Subject: RE: Store surviving a shutdown
> > > 
> > > Hi Aaron,
> > > 
> > > yes we are running the latest version from CVS and yes we
> > get the two
> > > files and they are both not empty.
> > > 
> > > But on startup the files are overwritten. Is there any
> > configuration
> > > for this perhaps?
> > > 
> > > Carsten
> > > 
> > > > -----Original Message-----
> > > > From: Aaron Smuts [mailto:aasmuts@wisc.edu]
> > > > Sent: Tuesday, May 18, 2004 2:25 PM
> > > > To: 'Turbine JCS Developers List'
> > > > Subject: RE: Store surviving a shutdown
> > > > 
> > > > The latest jcs version if shutdown properly, should write
> > two files
> > > > per region.  One called keys the other data.  One startup
> > it should
> > > > read the keys into memory and everything in the data folder
> > > should be
> > > > available just as before shutdown.
> > > > 
> > > > You need to make sure that the elements in the regions are not 
> > > > expiring also.
> > > > 
> > > > Are you getting the two files?  If not, did you build 
> the latest 
> > > > version of jcs from source?
> > > > 
> > > > Cheers,
> > > > 
> > > > Aaron
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > > > > Sent: Tuesday, May 18, 2004 5:36 AM
> > > > > To: 'Turbine JCS Developers List'
> > > > > Subject: RE: Store surviving a shutdown
> > > > > 
> > > > > Just an additional info:
> > > > > It seems that the files are written properly on
> > shutdown, but on
> > > > > startup they are overwritten with empty files.
> > > > > 
> > > > > Carsten
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Upayavira [mailto:uv@upaya.co.uk]
> > > > > > Sent: Tuesday, May 18, 2004 9:46 AM
> > > > > > To: turbine-jcs-dev@jakarta.apache.org
> > > > > > Subject: Store surviving a shutdown
> > > > > >
> > > > > > Hello, another Cocooner popping in for a visit!
> > > > > >
> > > > > > In our explorations of JCS, one thing I believe that was
> > > > said about
> > > > > > it is that the store doesn't persist through a shutdown.
> > > > > >
> > > > > > Now, the current (slightly buggy) implemention within
> > > > Cocoon does. 
> > > > > > Is there any way to make it persists through a restart,
> > > > or to make
> > > > > > it configurable?
> > > > > >
> > > > > > The main usecase for Cocoon is running within a
> > servlet, where
> > > > > > arguably surviving a shutdown isn't crucial. However,
> > > > Cocoon can be
> > > > > > used from the command line to statically generate web
> > > sites. For
> > > > > > this, a working persistent cache that survives
> > shutdown can be
> > > > > > invaluable. Each time you run it, it can check to see
> > > > whether a page
> > > > > > in the cache is up-to-date, and if so, not bother
> > > generating the
> > > > > > page. This should be able to offer a great performance
> > > > improvement
> > > > > > (but didn't because our previous implementation of a
> > persistent
> > > > > > store was slow). So you'd make me a happy man if you
> > gave me a
> > > > > > responsive persistent store that could survive a shutdown.
> > > > > >
> > > > > > Regards, Upayavira
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > turbine-jcs-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > turbine-jcs-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: 
> > > > turbine-jcs-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > turbine-jcs-dev-help@jakarta.apache.org
> > > > 
> > > > 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: 
> > > turbine-jcs-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > > > turbine-jcs-dev-help@jakarta.apache.org
> > > > 
> > > 
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: 
> > turbine-jcs-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> > > turbine-jcs-dev-help@jakarta.apache.org
> > > 
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> turbine-jcs-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> turbine-jcs-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org


Mime
View raw message