[MGNLADVCACHE-66] Site aware cache could retrieve mappings from site definitions which would simplifying configuration Created: 11/Jan/16  Updated: 18/May/16  Resolved: 24/Mar/16

Status: Closed
Project: Advanced Cache
Component/s: core
Affects Version/s: 1.7
Fix Version/s: 1.7.3

Type: Bug Priority: Neutral
Reporter: Rico Jansen Assignee: Roman Kovařík
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Centos 7


Issue Links:
Relates
causality
is causing MGNLCACHE-135 Starting site-aware advanced cache po... Closed
dependency
depends upon MGNLCACHE-132 AbstractListeningFlushPolicy#getPath ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Visible to:
Mathijn Elhorst, Michiel Meeuwissen, Nils Breunese
Sprint: Kromeriz 36
Story Points: 3

 Description   

The advanced caching module creates several caches when 'createSeparateCachesForEachSite' is set. Each cache is created with the name of the site definition.

When caching the info.magnolia.module.advancedcache.filter.SiteAwareCacheFilter takes care of storing and serving the content in the corresponding site cache.

However the info.magnolia.module.advancedcache.SiteAwareFlushAllListeningPolicy which
extends from info.magnolia.module.advancedcache.AbstractSiteAwareListeningFlushPolicy does not use this mechanism. Instead it uses the cache name (which is the site definition name) as the path to the root of the tree in the workspace to watch. This observation is started in info.magnolia.module.cache.AbstractListeningFlushPolicy using the path provided by the FlushPolicy.

This breaks flushing in our case because of two reasons:

  • The site definition is called pip-buitenhof but the node in the workspace buitenhof
  • The site does not live at the root but in /programma/buitenhof

A second problem we don't encounter in our case is the fact that there is no discrimination between workspaces for the path. So the multisite content needs to live a the same place in all workspaces that are multisite aware.

It would be better if the FlushPolicy used the sitedefinition and its repository mappings to register the correct path and workspace to observe.


Generated at Sun Feb 11 23:10:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.