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

Hi Galder, thanks, some answers are inline: 2010/8/6 Galder Zamarreño <galder(a)redhat.com&gt;: Not totally relevant, but there are two threads writing to the index directly, and they share a third thread - which is started by Lucene - doing some background writing too (optimizes the structure). As you say if the design was wrong I'd expect the failures to happen also without having any store configured, but this is a scenario I've been stresstesting a lot already and no issues where found. I initially introduced the SKIP_LOCKING flag as for some yet-have-to-understand-reason I was getting lock timeout exceptions on the get()s - Manik mentioned the L1 about this. The trick behind the fact that I don't need the locks is that by Lucene's design all segments are immutable: so unless a writer is not done with a segment, no one else is able to read it. When any thread is reading a segment, you're guaranteed that no more writes are going to happen on that segment. The only tricky part is that segments might be deleted while others are attempting to read it, but we handle that. I'm going to try and see what happens if I remove Flag usage, just to see why I'm the only one reporting corrupt data in the stores. I guess that locking might have some effect beyond my knowledge of Infinispan. I'm full of hope that someone will have some more time; thanks for all the help and have nice vacations! Cheers, Sanne