The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Spun off from #2228949: Allow Disabling of Client-side Queue Running, which deviated too much making this an issue on its own.
I have been testing the latest 7.x-1.2-beta1 and the latest code causes Acquia Purge to run after Akamai, aka the wrong order.
I think this is because the actual purge call isn't being made in acquia_purge_expire_cache, it just adds URLs there. And maybe because we are using the lateruntime variable?
We added support in the Akamai module to check if Acquia Purge was enabled and make it run at the end, here is the commit - http://cgit.drupalcode.org/akamai/commit/?id=4324aed3e40d49569251da2fac7...
I have been trying to fix it but it isn't coming easy to me, any ideas? We can maybe reroll a patch to Akamai to make it work with this new way in AP.
Given the fact that http://drupal.org/project/purge will fix this for Drupal 8 at architectural level, this should in my opinion be seen as a best attempt.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | akamai-getting_acquia_purge_work_with_akamai-2521530-13.patch | 1.09 KB | a_khalipau |
Comments
Comment #1
elijah lynnComment #2
a_khalipau commentedComment #3
a_khalipau commentedMoving this to Akamai issue queue.
Comment #4
a_khalipau commentedComment #5
a_khalipau commentedI worked with Elijah Lynn on this decision. It works for Acquia Purge 1.2 and later.
Comment #7
dave reidDoesn't this set a bad example for other modules? Why can't modules do their clearing in hook_expire_cache(), and rely on hook ordering to run them in the correct order if needed?
Comment #8
a_khalipau commentedComment #9
a_khalipau commentedComment #10
elijah lynnI wish I could tell you why but I am not sure of the reason the actual purging got moved to hook_expire in Acquia Purge.
Comment #13
a_khalipau commentedComment #14
elijah lynnDave has a good point. I am going to move this back to Acquia Purge for now.
AP should be doing its purging inside acquia_purge_expire_cache(). Why was the purging moved to acquia_purge_exit()? I am guessing there is a reason but it wasn't obvious to me.
I don't think this patch would be needed if it used hook_expire_cache() like the API is intended to be used.
Thanks
Comment #15
gg4 commentedI feel like we should expand the scope of this issue with the goal of getting Acquia Purge to work with all other CDN related modules that follow Expire integration best practices like Fastly.
In addition to the points already discussed, it would be good to improve the way this module is manipulating the Expire configuration pages, see: http://cgit.drupalcode.org/acquia_purge/tree/acquia_purge.module?h=7.x-1....
There are likely other improvements as well.
Comment #16
nielsvm commentedSo this is exactly what I refactored 7.x-1.4 into. Initially reluctantly, but it is now possible to register and provide a "executor" plugin that executes the cache invalidation against Akamai. The added benefit is that Akamai invalidations will benefit Acquia Purge's queue mechanism, its quality of service model (by allowing failures) and the fact that execution happens after the Acquia layer was cleared.
As its up to the Akamai module to provide its plugin, I'm now moving the issue to it.
PS.
7.x-1.4isn't released yet but soon will be, check out -dev release.Thank you everyone!
Comment #17
WidgetsBurritos commentedPostponed pending #3244672: Seeking 7.x Maintainer
Comment #18
smustgrave commentedWith D7 EOL lets close D7 tickets. Thanks!