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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > > 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:[EMAIL PROTECTED] > > > > 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:[EMAIL PROTECTED] > > > > > 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:[EMAIL PROTECTED] > > > > > > Sent: Tuesday, May 18, 2004 9:46 AM > > > > > > To: [EMAIL PROTECTED] > > > > > > 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: > > > > [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
