Outdated cache of release download table is not refreshed [#2843527]

I moved a current sql backup from production to dev machine.

When looking at project nodes the releases table is not refreshed. I cleared core cache and views cache several times. Nothing changed. The content still has links to the production site and has not rebuild the incorrect links in the table.

After some digging I TRUNCATE TABLE cache_project_release_download_table;. After reloading project nodes the cache was rebuild.

And now one more issue came in my mind. The Notes and Edit links disappeared from the releases table. Compared to the live site and found these Links are still there, but I guess they should no longer shown. They are shown for both anonymous and logged in users - what makes not much sense if it comes to Edit.

This means the cache need to be rebuild. There is no easy way to do this or I have not found any. These cache_project_release_download_table contains HTML code in a blob field that is never updated or only if you edit some stuff what nobody does.

Comments

Comment #1

14 January 2017 at 15:30

hass created an issue. See original summary.

Comment #2

hass CreditAttribution: hass commented 14 January 2017 at 15:36

Issue summary:

View changes

Comment #3

drumm

he/him

NY, US

CreditAttribution: drumm at Drupal Association commented 16 January 2017 at 20:31

The notes and edit links were removed with #2262073: Remove edit link from download table

Comment #4

drumm

he/him

NY, US

CreditAttribution: drumm at Drupal Association commented 17 January 2017 at 23:54

For clearing the cache - I've been feeding cache_clear_all('*', 'cache_project_release_download_table', TRUE); to drush. A UI would be nice to add.

Not having it clear on cache clear all helps soften cache stampeding.

Comment #5

hass CreditAttribution: hass commented 18 January 2017 at 00:04

Thanks for clarification that I cleared it correctly.

But why should the cache clearing use a different logic than page/block and other caches? I always hate that Views has it's own cache-clear... if every module implements it's own cache clear mechanism we end up in a real mess. I'm not a fan of this.

Comment #6

dww

we/he/they

CreditAttribution: dww as a volunteer commented 18 January 2017 at 19:28

@hass: Because of what drumm said -- if *every* cache clears simultaneously, then performance life sucks tremendously immediately after a cache clear, especially on a site at the scale of Drupal.org.

That said, yes:

A) Bug: this cache probably needs to be invalidated programmatically more often than it is. There are conditions that should trigger an invalidation which apparently aren't happening as expected.

B) Feature: sure, we could add a UI to clear this cache, perhaps per-project, and/or site-wide.

Comment #7

hass CreditAttribution: hass commented 18 January 2017 at 22:24

Sorry, I should have not written this as question. It was clear to me that clearing all caches is a short performance penalty for large sites like d.o.

I may better asked how d.o manages this cache-clear performance penalty for other pages. It looks not right to me that every module try to build something special for caching. It's better to integrate with standard core api's and reuse existing core caching logics.

Highly interrested how the performance issues are solved for other cache tables on d.o. That caching issue cannot be a problem of project module only.