We verified the issue while using the Lucene Directory; using the Directory under stress leads to no issues even during long running tests of several hours.

To verify the Lucene Directory under stress, use org.infinispan.lucene.profiling.PerformanceCompareStressTest.
The same exact test - but having a jdbc store enabled - breaks: org.infinispan.lucene.profiling.CacheStoreStressTest

Lucene's error says "invalid checksum", the truth is that the checksum data is missing as there where two consecutive put operations: one containing the correct data but missing the checksum signature, and then again putting the same data but with the correct signature; both puts are using SKIP_LOCKING, and it appears that some readers in other threads - which definitely start after the second put - are getting the first unsigned values (under load only - must be a race condition).

• The CacheStoreStressTest was committed with ISPN-590 as #2187, but same commit also works around the issue in the Lucene implementation, so keep the implementation at a previous revision.