Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-575

Wrong reordering of data when using Flag.SKIP_LOCKING and having a cache store enabled

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Obsolete
    • 4.0.0.Final, 4.1.0.CR2
    • None
    • Loaders and Stores
    • None
    • Hide

      see description

      Show
      see description

    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.

      Attachments

        Issue Links

          Activity

            People

              sgrinove Sanne Grinovero
              sgrinove Sanne Grinovero
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: