OK. Again thanks for the quick response!
-----Original Message----- From: Aaron Smuts [mailto:asm...@yahoo.com] Sent: Wednesday, August 12, 2009 9:49 AM To: JCS Users List Subject: RE: index cache corruption I was getting ahead of myself. I need to add removeMatching methods all over the place. And I need to work on the getMatching a bit. Don't change any of your code yet. Cheers, Aaron --- On Wed, 8/12/09, Tim Cronin <tim.cro...@autonomy.com> wrote: > From: Tim Cronin <tim.cro...@autonomy.com> > Subject: RE: index cache corruption > To: "JCS Users List" <jcs-users@jakarta.apache.org> > Date: Wednesday, August 12, 2009, 7:44 AM > > >This should probably deprecated for the remove matching > method > > I see these off of the JCS object: > > http://jakarta.apache.org/jcs/apidocs/org/apache/jcs/access/CacheAccess.html#getMatching(java.lang.String) > > > http://jakarta.apache.org/jcs/apidocs/org/apache/jcs/access/CacheAccess.html#getMatchingCacheElements(java.lang.String) > > I don't see a remove so do I need to use these to get the > keys then call remove? > > > -----Original Message----- > From: Aaron Smuts [mailto:asm...@yahoo.com] > > Sent: Wednesday, August 12, 2009 8:52 AM > To: JCS Users List > Subject: RE: index cache corruption > > > So were you getting back the wrong data or data that should > have been deleted? > > Are you running a recent temp build? > > I'll dig into the partial key removal. This should > probably deprecated for the remove matching method. . . > . Either way, it should work. > > Aaron > > --- On Tue, 8/11/09, Tim Cronin <tim.cro...@autonomy.com> > wrote: > > > From: Tim Cronin <tim.cro...@autonomy.com> > > Subject: RE: index cache corruption > > To: "JCS Users List" <jcs-users@jakarta.apache.org> > > Date: Tuesday, August 11, 2009, 2:30 PM > > Good to know, thanks. > > > > Yes that's when we see it too, under high load. > > > > For us it seems to happen around removes, we use the > key: > > linkage and > > It happens to data that's linked and would get cleared > with > > the key: > > call. > > > > > > -----Original Message----- > > From: Al Forbes [mailto:forbes...@googlemail.com] > > > > Sent: Tuesday, August 11, 2009 4:13 PM > > To: JCS Users List > > Subject: Re: index cache corruption > > > > Hi Tim, > > > > I had the same problem. It seems to happen under high > load, > > with fairly > > large objects, but I could not reproduce it offline. > I > > changed to using > > a > > JDBC cache and have not had a problem since then. > > > > We still use disk caches for more static data - mostly > read > > only, and > > the > > problem never happens there, so I assume it's the > writes > > that cause the > > corruption. > > > > Regards > > Al > > > > 2009/8/11 Tim Cronin <tim.cro...@autonomy.com> > > > > > We initially were using indexed disk cache but > ran > > into cache > > corruption > > > where the data returned for a key would not be > the > > data associated for > > > that key. I haven't been able to come up with a > good > > repro scenario... > > > > > > We had to work around it with the following > code: > > > > > > /** > > > * is the cache element not the > > correct object for the key > > > * @param key the current key > > > * @param element the current element > > associated with the key > > > * @param hasReadLock whether caller > > has read lock > > > * @return true if key mismatch els > > false > > > * @throws InterruptedException if > > locking fails > > > */ > > > private boolean isCorrupt(String key, > > ICacheElement element, boolean > > > hasReadLock) throws InterruptedException > > > { > > > boolean corrupt = > > !key.equals(element.getKey()); > > > if (corrupt) > > > { > > > mLogger.error("cache corruption!!! > > [" + (mCorruptionCounter++) + > > > "]"); > > > > > > if (mLogger.isDebugEnabled()) > > > { > > > mLogger.error("culprit > > stack...", new Exception("cache > > > corruption")); > > > } > > > > > > try > > > { > > > if (hasReadLock) > > > { > > > > > mLock.readLock().release(); > > > } > > > > > mLock.writeLock().acquire(); > > > try > > > { > > > > > mLogger.error("purging " + key); > > > mCache.remove(key); > > > mCache.remove(key + > > ":"); > > > } > > > catch (Exception e) > > > { > > > > > mLogger.error("failed to purge key " + key, e); > > > } > > > try > > > { > > > String k = > > (String)element.getKey(); > > > > > mLogger.error("purging " + k); > > > mCache.remove(k); > > > mCache.remove(k + > > ":"); > > > } > > > catch (Exception e) > > > { > > > > > mLogger.error("failed to purge key " + > element.getKey(), > > e); > > > } > > > } > > > finally > > > { > > > if (hasReadLock) > > > { > > > > > mLock.readLock().acquire(); > > > } > > > > > mLock.writeLock().release(); > > > } > > > } > > > return corrupt; > > > } > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > > > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org For additional commands, e-mail: jcs-users-h...@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org For additional commands, e-mail: jcs-users-h...@jakarta.apache.org
