CiviCRM Community Forums (archive)

What is the best way to ensure CiviCRM is using dynamically generated server paths rather than cached versions?

Currently when server paths change, CiviCRM cannot start because it is still calling the cached version of those paths. In many use cases this is a minor inconvenience because one can manually clear the cache. But on servers such as Pantheon (and possibly Platform.sh) where the server paths change dynamically to deal with server instability or cloning the site, CiviCRM just can't keep up. The result can be lots of 502 Gateway errors and other failures. As far as I can tell CiviCRM calling an incorrect server path is the single biggest point of failure.

Background: I've moved a client's Drupal 7/CiviCRM site to Pantheon recently. I had started with CiviCRM Starterkit but found that it was still not working properly and the original developer of that install profile has limited availability. The site is now using mostly stock CiviCRM.

When I spoke to Pantheon support, this is how they explained their setup:

"On the Pro level you have one app container and a failover that is usually dormant. Appserver bindings are meant to be ephemeral and will change whenever we detect server instability or need to migrate to push updates, so age varies."

My original idea was to trigger cache rebuild when it detected the server paths had changed, but this proved to be unworkable since the server paths could change often as a failover and main app container switched back and forth quickly.

Note: in Pantheon,  server paths also need to be set http://wiki.civicrm.org/confluence/display/CRMDOC/Override+CiviCRM+Settings in civicrm.settings.php using Pantheon's dynamic environment variables for the server bindings. So this part works, but the result is then cached, which is the problem.

So my current best hope is to not use the cached versions of server paths at all. The most elegant solution would be one that was accepted into core since this could be useful for any similar system.

As a short-term measure I've removed these lines from the Singleton function in CRM/Core/Config.php:

$cache = CRM_Utils_Cache::singleton();
self::$_singleton = $cache->get('CRM_Core_Config' . CRM_Core_Config::domainID());
and

$cache->set('CRM_Core_Config' . CRM_Core_Config::domainID(), self::$_singleton);
This means that no config is stored in cache and CiviCRM has to rebuild it every time that the Config Singleton is rebuilt. I don't know if that's a huge problem or not (there might be situations where it is), but it doesn't seem to have made an appreciable difference in load times. I haven't tested it under load. The real test will be with a mailing or something similar. I hope to have the results of that soon, and fingers crossed, it'll handle it well.

But I wanted to put this out there to see if there are better approaches. Thank you!

Thanks for the reply Chris.

Storing relative paths makes sense to me. The full path can be discovered each time, much like what is done when the cache is first created now. Like you, though, I'd need to know what disadvantage there is to this and if it would introduce a regression.

IPN calls the same Config Singleton so either way it could build the absolute path in the same way, no?

By the way, so far the client hasn't had any issues with my hack to skip the cached config and just rebuild it if the singleton isn't available. They've done a couple large mailings and it seems to have gone through fine. And no complaints about payments not working or being slow (it might be slower but I haven't heard from the client on real world issues).

Not that I know of Ryan.