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

L1: On topology changes lose key requestors information

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • Blocker
    • 5.2.0.CR1
    • 5.1.0.FINAL
    • Core
    • None

    Description

      I think we are losing information about where a key needs to be invalidated when a node changes from owner to non-owner (e.g. because another node joined):

      • We lose the list of requestors stored on this node. Even if all ClusteredGetCommands reached all the current owners (which we are about to change with ISPN-825), once all the current owners leave the new owners will not know about this node's old requestors.
      • We don't add ourselves as a requestor for the key on the new owners when we invalidate the entry and move it to L1.

      Attachments

        Issue Links

          incorporates

          Bug - A problem that impairs or prevents the functions of the product. ISPN-2474 L1 entries should be invalidated when the key ownership changes

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. ISPN-2475 When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed
          is duplicated by

          Bug - A problem that impairs or prevents the functions of the product. ISPN-2172 Cache removals not removing L1 cached values in non-owners after rehashing

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              dberinde@redhat.com Dan Berindei (Inactive)
              dberinde@redhat.com Dan Berindei (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: