[infinispan-issues] [JBoss JIRA] Updated: (ISPN-575) Wrong reordering of data when using Flag.SKIP_LOCKING and having a cache store enabled

[Sanne Grinovero (JIRA)]

     [ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sanne Grinovero updated ISPN-575:
---------------------------------

           Description: 
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.


  was:
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.

If during the same stress test a permanent store is enabled, all works still fine, until the CacheManager is stopped. No errors during the stop(), but after starting it again the checksum on some data fails and the index is unusable.

    Steps to Reproduce: see description  (was: Reconfigure org.infinispan.lucene.profiling.PerformanceCompareStressTest to use a permanent store, start it, wait it to finish, stop it and try starting it again: it likely won't, but is not always reproduced.)


> Wrong reordering of data when using Flag.SKIP_LOCKING and having a cache store enabled
> --------------------------------------------------------------------------------------
>
>                 Key: ISPN-575
>                 URL: https://jira.jboss.org/browse/ISPN-575
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Loaders and Stores
>    Affects Versions: 4.0.0.Final, 4.1.0.CR2
>            Reporter: Sanne Grinovero
>            Assignee: Mircea Markus
>            Priority: Critical
>             Fix For: 4.1.0.CR3, 4.1.0.Final
>
>         Attachments: [ISPN-575]_(Corruption_in_data_when_using_a_permanent_store)_Extra_debugging_info_.patch, ISPN-575-previewOfTest-dontapply.patch
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira