Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39097

Remove deprecated "pattern" cache update event handling



    • Type: Bug
    • Status: CLOSED
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 10.0
    • Fix Version/s: 10.0, 11.0
    • Component/s: Kernel
    • Labels:
    • 10 status:
    • Previous Issue Keys:


      See KNL-1162

      This ticket is for removing the deprecated use of patterns in the caches. All caches which call:
      Cache MemoryService.newCache(String cacheName, CacheRefresher refresher, String pattern)
      Cache MemoryService.newCache(String cacheName, String pattern)
      will be switched over to:
      Cache MemoryService.newCache(String cacheName)

      Any cache entry expiration will need to be handled manually at that point.

      The caching pattern (which is optionally configured when a cache is created) was meant to be a way to automatically remove entries in a cache when a change event occurs which matches the start of the pattern. In practice, this means the ref from the Event is checked against the pattern and if the ref startsWith the same chars then the cache entry that has a key matching that Event ref will be removed from the cache.
      This is probably better handled in each service using the cache (and in some cases it is also handled in the service). For now, I am marking the pattern as deprecated but keeping the functionality in place.

      Pattern cache used in:

      Pattern caches:

      Stats from a fairly high load server:
      org.sakaiproject.user.api.UserDirectoryService.callCache: count:4375 hits:4685826 misses:12141 hit%:99
      org.sakaiproject.site.impl.SiteCacheImpl.cache: count:9810 hits:8841581 misses:667179 hit%:92
      org.sakaiproject.alias.api.AliasService.callCache: count:1 hits:2 misses:7 hit%:22

      Looks like the alias cache is basically worthless. The other 2 are critical though.

      NOTE: we added the alias callCache back in for 10. It will be disabled for anyone using the new caching system

      Solution note:
      Viable options are only to have the event based stuff work while non-distributed caches are used (on a cache by cache basis) and disabled when distributed caches are used. Luckily, this only affects 2 current caches as all other caches do not properly invalidate across a cluster (and some do not even properly invalidate locally).
      To support existing behavior I am willing to make the user and security caches work like they did but that mechanism should be handled in the code where the cache is used and should disable itself when the cache is distributed. That means MemoryService needs to have an API that allows someone to know if a cache is distributed for the short term. In the longer term we would simply not support the Sakai event flavored cache expirations.

      Institutions who want a distributed cache would need to setup a real one like memcached or hazelcast or terracotta. This is in line with other LMSs (e.g. Moodle) and the majority of the software industry (e.g. Drupal) in general.

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  aaronz Aaron Zeckoski (Inactive)
                  aaronz Aaron Zeckoski (Inactive)
                • Votes:
                  0 Vote for this issue
                  5 Start watching this issue


                  • Created:

                    Git Source Code