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

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero closed ISPN-575.
--------------------------------

    Fix Version/s:     (was: 5.1.0.BETA1)
                       (was: 5.1.0.FINAL)
       Resolution: Out of Date


We agreed this is not a supported case: locks are needed to avoid data inconsistencies and should not be skipped lightly.

The issue is no longer an issue when using the Lucene Directory, as it no longer attempts to write twice on the same key sipping the lock.

> Wrong reordering of data when using Flag.SKIP_LOCKING and having a cache store enabled
> --------------------------------------------------------------------------------------
>
>                 Key: ISPN-575
>                 URL: https://issues.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: Sanne Grinovero
>            Priority: Critical
>         Attachments: ISPN-575-previewOfTest-dontapply.patch, more_logs.patch, [ISPN-575]_(Corruption_in_data_when_using_a_permanent_store)_Extra_debugging_info_.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.
For more information on JIRA, see: http://www.atlassian.com/software/jira