Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-7882

Atomic update requests should always use topology mappings instead of affinity



    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 2.4
    • None
    • cache
    • None


      Currently for mapping cache atomic updates we can use two ways:
      1) Use nodes reporting status OWNING for partition where we send the update.
      2) Use only affinity nodes mapping if rebalance is finished.

      Using the second way we may route update request only to affinity node, while there is also node which is still owner and can process read requests.

      It can lead to reading null values for some key, while update for such key was successful a moment ago.


      Problem with using topology mapping:

      1) We send update request with key K to near node N
      2) N performs mapping for K to nodes P, B1, B2, B3 (Primary and backups) and starts waiting for succesful update responses for all of these nodes.
      3) N sends update request to P. During this time B3 change status to RENTING (Eviction).
      4) P also performs mapping for K to backup nodes B1, B2.
      5) All updates are succesful, but N is still waiting for response from B3. Update request will be not finished and hangs.


        Issue Links



              jokser Pavel Kovalenko
              jokser Pavel Kovalenko
              0 Vote for this issue
              3 Start watching this issue