>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
