Ok, it seems that we have two problems: - if only a few objects are cached, this is not persisted on shutdown. It seems that there has to be a critical mass for this. - although on startup the objects are read (at least the log message indicates that all keys are found), the keys are either not found or do not match - this might be due to our custom keys we use, I will further investigate.
Carsten > -----Original Message----- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 19, 2004 8:39 AM > To: 'Turbine JCS Developers List' > Subject: RE: Store surviving a shutdown > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
