What kinds of unreliability do you see with the indexed disk cache? I don't know of any.
Aaron --- Tim Cronin <[EMAIL PROTECTED]> wrote: > Thanks for the information. > > We use 1.5 as well and it would be nice to > standardize > on that. > > Do you know if the Block Disk Cache is any more > reliable > than the indexed it seems like the impl is simpler? > > > -----Original Message----- > From: Al Forbes [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 11:28 AM > To: JCS Users List > Subject: Re: cache corruption > > The project is not really actively developed - it > has the features > most folks require so it's mostly in maintenance > mode. > > If there are defects they are generally very > difficult to reproduce. > Personally I do not think it is worth tracking down > threading/synchronization until we move to jdk1.5. > We could try using > the back-ported concurrent library, but I'm not sure > that offers much > benefit. With so few changes, any change using the > standard jdk15 > library could easily be back-ported to the jdk13 > version of JCS. > Jdk1.5 is already 3.5 years old, so most people have > upgraded. > > But Aaron is the biggest contributor, so it's really > up to him to > decide. > > > > On 13/02/2008, Tim Cronin <[EMAIL PROTECTED]> > wrote: > > yes using indexed disk cache. > > > > We can't afford to move to DB at this time... > > > > Still trying to come up with at scenario to repro > > > > I did notice some private members on the caches > > > > IndexDiskCache.checkKeyDataConsistency(boolean) > > > > LRUMemoryCache.verifyCache() > > > > I can reflect into these if the error occurs > > > > I don't see any defects In jira only the one > > about hitting the cache files from different jvms. > > > > The project seems quite is it still actively > developed? > > > > -----Original Message----- > > From: Al Forbes [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 12, 2008 3:11 PM > > To: JCS Users List > > Subject: Re: cache corruption > > > > Tim, > > > > Are you using the disk cache? I had many problems > with a large disk > > cache, but nothing since switching to a database > cache. I suspect my > > problem had something to do with the shutdown or > inconsistencies after > > a forced shutdown. > > > > Al > > > > On 12/02/2008, Tim Cronin <[EMAIL PROTECTED]> > wrote: > > > We use jcs (1.3) in a web application, and over > time we're seeing > > where > > > > > > two different keys (string based key) point to > the same object > > > > > > say we have key "a" key "b" if I call > JCS.getCacheElement("a") > > > > > > I get the element where the key = "b". I then > call > > > > > > JCS.remove("b") then call JCS.get("b") I get > null > > > > > > but if I call JCS.get("a") I get the object > cached for "b" > > > > > > and subsequent calls to JCS.get("b") now return > the object. > > > > > > only if call JCS.remove("a") will the problem be > fixed. > > > > > > it also seems to "right" itself over time I > believe if it > > > get dropped from the cache. > > > > > > I was able to see the key mismatch using the > JCSAdmin.jsp > > > to interrogate the cache. > > > > > > I'm trying to track down exactly when this > happens. > > > > > > > --------------------------------------------------------------------- > > > 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]
