[MGNLCACHE-75] Make it possible to share default configuration between multiple caches Created: 12/Sep/14  Updated: 23/Feb/15  Resolved: 16/Feb/15

Status: Closed
Project: Cache Modules
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4

Type: Improvement Priority: Neutral
Reporter: Stefan Baur Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLADVCACHE-43 Use site configuration instead of con... Closed
relation
is related to MGNLCACHE-55 Caching arbitrary objects Closed
supersession
supersedes MGNLCACHE-82 Runtime reconfiguration without killi... 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)
Date of First Response:

 Description   

Hi

Currently, info.magnolia.module.cache.filter.CacheFilter#onCacheModuleStart uses cacheConfigurationName to read the cache configuration and to create the cache.

This means that you force the usage of a different cache per cache filter.

If you have to setup multi site caching (https://documentation.magnolia-cms.com/display/DOCS/Advanced+Cache+module#AdvancedCachemodule-Multisitecacheconfiguration), you will end up with N cache filters and N cache configurations.

Maybe a second property cacheName on the filter will do the magic. And you can always fallback to cacheConfigurationName if cacheName is not set.

Cheers,
Stefan



 Comments   
Comment by Magnolia International [ 15/Sep/14 ]

Hey Stefan,

Thanks for the idea. MGNLCACHE-55 introduces some configuration changes, which actually make it possible to configure different caches (stuff like eviction policy of ehcache etc was until not configurable per-cache). It also makes it a little simpler/more obvious to have a "Cache Configuration" (which we now call ContentCachingConfiguration) using a different/specific cache. It defaults to using the same name (e.g if CCC is called "foo", it will use a cache called "foo" unless configured explicitly to use "bar")

This doesn't solve your problem but I actually see two further issues after this, not just one:

  1. Indeed, you still need a ContentCachingConfiguration
  2. You still need N CacheFilters.

I'd suggest the following:

  • Advanced cache module provides a SiteAwareCacheFilter - when no specific config name is provided, it falls back to a well-defined naming scheme for the ContentCachingConfiguration (e.g site-<sitename>-config for instance, whereas the default cache filter simply falls back to "default")
    • If no CCC is configured with the given name nor the fallback/generated name, further fallback to "default" or some other name. (-> now you have 1 filter for all your sites, where some sites can benefit from their own CCC, and others fallback to a default)
  • SiteAwareFlushAllListeningPolicy needs to be updated accordingly.
Comment by Stefan Baur [ 15/Sep/14 ]

Hi Greg.
Thanks for the detailed answer! Happy that you understood the paint points

Advanced cache module provides a SiteAwareCacheFilter

Does this mean that this class should already exist in the current release, or is already prepared for to be released with 5.4, or could be released in the future?

Since yesterday, I have also noticed that the 1:1 mapping between cache configuration and cache (=Ehcache) instance is also implicitly made in other places.

This seems to happen in

  • info.magnolia.module.cache.filter.CacheFilter#onCacheModuleStart
  • info.magnolia.module.cache.CacheModule#start
  • info.magnolia.module.cache.CacheModule#stop
  • info.magnolia.cms.cache.pages.CacheToolsPage#getCacheSizes
  • info.magnolia.module.cache.commands.FlushCachesCommand#execute
  • info.magnolia.module.cache.commands.FlushFromCachesByUUIDCommand#execute

Cheers,
Stefan

Comment by Magnolia International [ 15/Sep/14 ]

I meant that Advanced Cache should provide such a filter in a future release - at the very least we'll register the issue in Jira, and hopefully we find time to get that into 5.4.

Ho and thanks for this name/config mapping analysis, it's actually quite helpful ! I fixed a couple of these places, but possibly not all !
(we've been hindered by MGNLCACHE-67)

Comment by Stefan Baur [ 17/Oct/14 ]

Good morning.

Do you have any news about

  • Will such features be integrated in 5.4?
  • When 5.4 will be released?

Cheers,
Stefan

Comment by Jan Haderka [ 09/Dec/14 ]

Hi Stefan,

yes we still plan to implement this feature for Magnolia 5.4.

The release date is plan for around end of March 2015.

Comment by Jan Haderka [ 15/Feb/15 ]

AbstractListeningFlushPolicy

  • moving getPath() method call out of the loop makes it possible to break initialization of other listeners should the overriden method throw exception. Actually whole init loop in start() method should be made more resilient so that we are sure we still initialize other listenerers even if one fails.

CacheFactory

  • why should CacheFactory know about ModuleLifecycleContext ever? this context is meant for module initialization only. What if we move initialization of cache elsewhere in the future? Or if we decide to change how modules are initialized? In either of those situations this kind of changes in the interface would become a problem, so we should rather avoid such changes in a first place.
Generated at Sun Feb 11 23:51:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.