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