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

Non-transactional INVALIDATION_SYNC cache deadlock

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Done
    • 10.1.8.Final, 11.0.5.Final, 12.0.0.Dev06
    • 12.0.0.CR1, 12.0.0.Final
    • Core
    • None
    • DataGrid Sprint #53
    • Hide

      Possible workarounds:

      • Use a transactional invalidation cache. Tx caches use the same locking scheme as replicated caches since ISPN-10029, but need more RPCs so are slower.
      • Use asynchronous replication (cache mode INVALIDATION_ASYNC).

      Because in this case the invalidation cache uses a RemoteStore backed by a HotRod cluster, it would also be possible to use a HotRod client with near-cache enabled. Performance characteristics are obviously very different since invalidations arrive from the servers, but ISPN-10216 will improve that a lot.

      Show
      Possible workarounds: Use a transactional invalidation cache. Tx caches use the same locking scheme as replicated caches since ISPN-10029 , but need more RPCs so are slower. Use asynchronous replication (cache mode INVALIDATION_ASYNC). Because in this case the invalidation cache uses a RemoteStore backed by a HotRod cluster, it would also be possible to use a HotRod client with near-cache enabled. Performance characteristics are obviously very different since invalidations arrive from the servers, but ISPN-10216 will improve that a lot.

    Description

      Non-transactional invalidation caches use the old locking scheme from Infinispan 4.x, which is prone to deadlocks:

      1. put(k, v1) is invoked on node A and acquires lock k
      2. put(k, v2) is invoked on node B and acquires lock k
      3. A sends an InvalidateCommand(k) RPC to B
      4. B sends an InvalidateCommand(k) RPC to A
      5. The InvalidateCommand(k) from A and tries to acquire lock k on B
      6. The InvalidateCommand(k) from B and tries to acquire lock k on A
      7. Both InvalidateCommand(k) lock acquisitions eventually time out and release lock k on their originators.

      Attachments

        Activity

          People

            dberinde@redhat.com Dan Berindei
            dberinde@redhat.com Dan Berindei
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: