Option to manually rebuild an aggregate with a new filename [#2728701]

On one site we had to disable advagg for... what turned out to be problems that weren't advagg's fault, so we're turning it back on again ;) One sporadic problem we've seen (three or four times over five months) with core's aggregation is that an aggregated file will become corrupted somehow, and we've had to push out a minuscule whitespace change to one of the files in the aggregate to make it create a new file. For those once-in-a-year (or four times in a year) situations where an aggregate file is corrupted, might there be an easy way to force the file to be regenerated with a new filename so that browsers are then instructed to load the new file, instead of use the corrupted older one? Thanks.

Comment	File	Size	Author
#4	2728701-add_timestamp_to_contents_hash.patch	930 bytes	logickal
#4	7.x-2.x: PHP 5.3 & MySQL 5.5, D7 6 pass PHP 5.6 & MySQL 5.5, D7 6 pass PHP 7 & MySQL 5.5, D7 6 pass

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

18 May 2016 at 17:48

DamienMcKenna created an issue. See original summary.

Comment #2

mikeytown2 CreditAttribution: mikeytown2 commented 19 May 2016 at 01:34

Thinking that the dirty shutdown might be the cause, and clearing mtimes might be the cure. If not I can add the change counter inside of the files table to the second hash; not including it if the shared multisite setting is enabled.

Comment #3

logickal CreditAttribution: logickal at The Weather Company commented 19 May 2016 at 16:42

My intitial thought was that adding the timestamp of generation to one of the hashes would also work...

Comment #4

logickal CreditAttribution: logickal at The Weather Company commented 20 May 2016 at 13:41

File	Size
2728701-add_timestamp_to_contents_hash.patch	930 bytes
7.x-2.x: PHP 5.3 & MySQL 5.5, D7 6 pass PHP 5.6 & MySQL 5.5, D7 6 pass PHP 7 & MySQL 5.5, D7 6 pass

Simple patch adding the timestamp to the aggregate file generation. Untested at this point, but just putting the idea out there.

Comment #5

mikeytown2 CreditAttribution: mikeytown2 commented 23 August 2016 at 23:53

Status:

Active

» Needs review

Comment #6

mikeytown2 CreditAttribution: mikeytown2 commented 24 August 2016 at 02:14

There are 3 hashes in an advagg filename.
- First is the list of files, this can't be adjusted.
- Second is the contents of the file, this is what you've been changing by doing a whitespace change; also what the patch in #4 does.
- Third is the advagg settings, incrementing the global counter (on the operations page) is one way to force out a change without changing a file; this just forces every aggregate to be regenerated as a result (big hammer).

What if we used the changes column in the advagg_files table as part of the second hash; I've never been a fan of using timestamps as part of the hash. On the operations page I could make a per file forced change ui; similar to the info page. I'll make this available if the Unified Multisite setting is not being used (a way to share aggregates across multisites if all settings match).

Comment #7

mikeytown2 CreditAttribution: mikeytown2 commented 26 October 2016 at 02:51

Status:

Needs review

» Active

Does the big hammer work for you guys or do you need something else? The patch in #4 will most likely be rejected, seems like it will create a lot of files; passes tests though.