XWiki Platform
  1. XWiki Platform
  2. XWIKI-13746

Users may loose access rights related to their group memberships on heavy loaded sites

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 5.4.7, 7.1.4, 6.4.8, 8.2.1, 7.4.5, 8.3-rc-1
    • Fix Version/s: 8.3, 8.4-rc-1, 8.2.2, 7.4.6
    • Component/s: Security
    • Labels:
      None
    • Difficulty:
      Unknown
    • Documentation:
      N/A
    • Documentation in Release Notes:
      N/A
    • Similar issues:

      Description

      When the security cache is near full capacity, the LRU eviction mechanism triggered by adding a new entry may cause that added entry to be removed through the cascading removal of child nodes of the evicted entry.
      That looks very unlucky (and this could be improved), but it happens more often than you first thought.
      Hopelessly, this trigger a deadlock issue in the cache container which recovers after 10 seconds. During these 10 seconds, the whole cache is write locked which is very bad for performance, but more importantly, the interrupted eviction create a corrupted situation, where nodes out of the cache, are still referenced from nodes still in the cache and that should have been evicted.

      This is the main issue. However, during investigation of it, I suspect that a race condition could also lead to a single thread taking wrong decision about user memberships. This is far less visible and persistent, but this could happen at anytime and could inject some wrong decision into the cache for a while. This race condition has been introduced when the usage of links between entries in the cache, initially only a means of eviction, has been reused for implementing an internal group cache. Since this is closely related, it will be fixed as well.

        Activity

        Hide
        Denis Gervalle added a comment - - edited

        The above description is closely related to the behaviour of the infinispan cache, but could be of any cache implementation that piggyback the users threads for proceeding with eviction. However, there is an important aspect of the current implementation that may require attention if the cache implementation change. The disposal process implemented during entries disposal may not be fully thread safe. It is currently always protected by the fair write lock implemented on the cache, because of the piggyback threading used by infinispan. I am pretty confident it would work, without it, but it is just not tested.

        Show
        Denis Gervalle added a comment - - edited The above description is closely related to the behaviour of the infinispan cache, but could be of any cache implementation that piggyback the users threads for proceeding with eviction. However, there is an important aspect of the current implementation that may require attention if the cache implementation change. The disposal process implemented during entries disposal may not be fully thread safe. It is currently always protected by the fair write lock implemented on the cache, because of the piggyback threading used by infinispan. I am pretty confident it would work, without it, but it is just not tested.
        Hide
        Denis Gervalle added a comment -

        Now when the cache eviction process bite its tail, delete the entry currently added, the addition fails and cause a restart of the load process. Except in very constrained situation, the next retries will succeed. In worse case, it will fails after five, but I don't believe this could ever happen with a normal cache size.

        Show
        Denis Gervalle added a comment - Now when the cache eviction process bite its tail, delete the entry currently added, the addition fails and cause a restart of the load process. Except in very constrained situation, the next retries will succeed. In worse case, it will fails after five, but I don't believe this could ever happen with a normal cache size.

          People

          • Assignee:
            Denis Gervalle
            Reporter:
            Denis Gervalle
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: