[MGNLRES-197] FarFuture caching needs rework of the concept: reference resources and the scriptloadres won't change modification date Created: 04/Jul/13  Updated: 29/Mar/22  Resolved: 21/Aug/15

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4

Type: Improvement Priority: Major
Reporter: Christian Ringele Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Resources-ReferenceResource-JustPointsToTarget.png     PNG File Resources-ReferenceResource-OnSelfRenderRendersTheTarget.png     PNG File Resources-Scriptloader-DefiningThe-URI-AndTimestamp.png     PNG File Resources-Scriptloader-JustRendersChilderen-ChildrenAreReferenceResources.png     PNG File Resources-TheActualFinallRenderedResource.png    
Issue Links:
causality
duplicate
duplicates MGNLRES-152 Generate links to resources, and use ... 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:
Team: Nucleus

 Description   

The STK's javascript loader libraries define by their modification date the time stamp in the far future caching strategy -> the url output of the resource.

This means when a resource, any JS for example, gets changed, the time stamp will remain the same because the scrip-loaders didn't change at all. The will still have the same modification date.

Possible solution:
Newest modification date of all resources is used.

Becuase there are many modulees involved, resources & STK & cache, I created this issue to main Magnolia project.

Also the Url pattern could be optimized. Long ago Aperto wrote a mail to Philipp, explaining problems they have with this URL pattern based on Apache rewrites and VirtualURIMappings.



 Comments   
Comment by Christian Ringele [ 26/Nov/13 ]

The included JS resource pints to the scriptloader-libraries.js with an additional resource (print screen Resources-Scriptloader-DefiningThe-URI-AndTimestamp.png):

<script src="/demo-project/resources/templating-kit/js/scriptloader-libraries.2013-06-05-18-23-32-183.cache.js" type="text/javascript"></script>

The time stamp is determind bz the modification date of the scriptloader-libraries.js resource node's modification date.
But that node basically never changes.
It just renders all children, and the children reference a real JS resource node.

So four situation when things change that would need a new URI time stamp:
1. A new real JS resource node is added and a new reference resource is added as a child node of the scriptloader-libraries.js
2. A new real JS resource node is added and a existing reference resource (child node of the scriptloader-libraries.js) is changed pointing to a new target.
3. A existing and used real JS resource node is changed (a target of a existing reference resource child node of the scriptloader-libraries.js was changed).
4. A child node of the scriptloader-libraries.js is removed (some JS is not needed anymore).

All 4 situations have no impact on the time stamp.
In situation 3 not the child nodes of the scriptloader-libraries.js changed.

Comment by Jan Haderka [ 07/Oct/14 ]

Possible solution I can think of

  1. disable FFC for all aggregated resources.
    • IMHO not really viable option
  2. when determining date of resource for FFC, perform deep analysis of all included (directly or via reference) resources.
    • IMHO such performance overhead that it would wipe out usefulness of FFC all together (in time it takes to calculate whether resource or its parts were modified, we would be able to serve such resource for most of the time).
  3. calculate FFC timestamp not from the date but from MD5/SHA of the content of generated script
    • pbly also not most "performant" option, but surely easiest to implement
  4. use observation to update timestamp or other property used to generate timestamp on the top most resource that is determined to be including given resource via reference or via hierarchy (update all the resources on the way up)
    • tough to implement
    • might get out of sync
    • will not cover all the cases such as when someone decided for write FM for processed script to include resources based on some other pattern then hierarchy downward
    • advantage, if using predefined property for storing of timestamp would be exposure of the timestamp for customisations by others
    • another advantage is that we might even store fully regenerated aggregated script under top most node and version that for the future comparison
Comment by Jan Haderka [ 21/Aug/15 ]

This issue have been resolved by MGNLRES-152

Generated at Mon Feb 12 06:48:20 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.