[infinispan-dev] Findings from the cache store corruption issue - ISPN-575

Galder Zamarreño galder at redhat.com
Fri Aug 6 16:17:00 EDT 2010


Hi Sanne,

I've looked at the CacheStoreStressTest in https://jira.jboss.org/browse/ISPN-575 and there's something I haven't understood:

In the test, there appears to be a single thread which is a writer and the rest are reading. Now, when looking to SingleChunkIndexInput constructor, it appears that you're skipping locking for reading the chunk via:

      buffer = (byte[]) cache.withFlags(Flag.SKIP_LOCKING).get(key);

If you skip locking, how do you guarantee that you won't be reading data that's in the process of being updated? Is there some other locking strategy used to guarantee that correct reads? However, if this was the cause of the issue, I'd imagine it'd fail when no cache store is present as well, wouldn't it? 

I'm away on vacation till next Friday, so don't have more time to look into it right now. I'm attaching a patch with some extra logging I've added. The key is finding out why the byte[] stored and retrieved are different. Maybe Mircea can help further from Monday onwards when he gets back from holidays?

One last thing, setting TRACE on org.infinispan is a bit exagerated, generates huges files and does not fail. I've been playing with setting TRACE to org.infinispan.loaders and org.infinispan.lucene

Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list