Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(dev/core#4055) ClassLoader - Use separate cache IDs for different configurations of modules #25379

Merged
merged 1 commit into from
Jan 20, 2023

Conversation

totten
Copy link
Member

@totten totten commented Jan 19, 2023

Overview

Possible alternative to #25235. It aims to address https://lab.civicrm.org/dev/core/-/issues/4055, although I don't know that my local system is suitable for testing.

Before

When you enable or disable an extension:

  1. It deletes the CachedExtLoader.{$envId}.php, then
  2. It creates a new version of CachedExtLoader.{$envId}.php, and finally
  3. It loads the new version of CachedExtLoader.{$envId}.php.

But in some environments, step (3) is reported to read stale data because the opcode cache has momentarily retained the old data.

After

When you enable or disable an extension, it changes the {$envId} used for the filename CachedExtLoader.{$envId}.php.

Since the {$envId} is different, it doesn't matter whether the opcode cache retains the old data -- because it's retained under the old name. The new name should be clean.

Comments

I haven't specifically tried to reproduce the scenario in 4055. Putting this up to see if the test-suite likes it.

ping @kainuk

@civibot civibot bot added the master label Jan 19, 2023
@civibot
Copy link

civibot bot commented Jan 19, 2023

(Standard links)

$envId = \CRM_Core_Config_Runtime::getId();
$envId = md5(implode(',', array_merge(
[\CRM_Core_Config_Runtime::getId()],
array_column($this->mapper->getActiveModuleFiles(), 'prefix')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that in terms of the tangential issue I hit - ie totten/civix#287 - that getActiveModuleFiles is loading from the possibly-last-build-relevant Redis - I'm trying to figure out the impact of this on that issue. I suspect it would be unchanged

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Off the top of my head -- I wouldn't expect an effect one way or the other.

In theory, if all the Redis caches had a similar prefix (eg dmaster/{$envAndModuleId}/{$cacheGroup}/{$cacheKey}), then that might mitigate the issue. But for the use-case of civibuild install or civibuild reinstall, I might lean toward updating the installer -- it should pre-emptively clear caches to ensure that the new install starts from a clean slate.

@kainuk
Copy link
Contributor

kainuk commented Jan 19, 2023

Hi @totten, I just tested this PR on my local machine, and solves the problem. The advantage of your solution that is does not change cache mechanism, but just targets the stale problem.

@eileenmcnaughton
Copy link
Contributor

MOP based on @kainuk's testing

test this please

@seamuslee001 seamuslee001 merged commit c71bd04 into civicrm:master Jan 20, 2023
@totten totten deleted the master-ext-cache branch January 20, 2023 00:15
@totten
Copy link
Member Author

totten commented Jan 20, 2023

Thanks @kainuk. Glad it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants