I'm currently experimenting with XAutoload and APC and right now I have 2 development sites both using it as the autoloader for APC. The first site runs great. As soon as I enable and configure the module on the second site I am starting to get fatal errors related to re-declaring classes (specifically within Views, but that could vary a bit).

I did some reading on APC itself and it sounds like I have most of the configuration right (based on this http://stackoverflow.com/questions/4575341/php-with-apc-fatal-errors-can...). I only have this problem with this module's APC loading, so something is odd. Am I missing something?

Thanks!

Comments

lalweil created an issue. See original summary.

donquixote’s picture

donquixote commented

Could it be that both sites use the same $drupal_hash_salt in settings.php?
Please report back if changing this fixes the problem for you. It means that I should change how the cache is implemented.

donquixote’s picture

donquixote commented

Hm, I think this is a dead end. I am still looking.
Also check #2627228: Clear caches

donquixote’s picture

donquixote commented

Can you compare the value of variable_get('xautoload_cache_prefix') on both sites?

mikemadison’s picture

mikemadison commented

Thanks for digging a bit!

The xautoload_cache_prefix variable is the same on both of the sites: NrDpdNmsgC7ZV2h48zTIIvMRByA7AG5.

I can confirm that the hash salts are not the same.

donquixote’s picture

donquixote commented

Ok.
For your personal case, it is sufficient to change the cache prefix on one of the sites.
The easiest is to delete the key, and it will be recreated automatically.

I still need to fix this in the module, because this is not a problem that should happen.

donquixote’s picture

donquixote commented
Related issues: +#2627228: Clear caches
donquixote’s picture

donquixote commented
Status: Active » Closed (duplicate)

Please have a look at comment #8 in #2627228-8: Clear caches

I close this one as duplicate, because it is really the same problem.

mikemadison’s picture

mikemadison commented

will keep an eye on it. thanks!

fuzzy76’s picture

fuzzy76 commented

We ended up with the same config problem when someone by accident exported the xautoload_cache_prefix variable into a feature that was deployed on numerous sites. Things got really interesting when they started loading each others classes...

Is there an easy one-liner to set this variable to a proper value? I see that the variable is saved in CacheManager.php, but I'm not sure where the value comes from...

donquixote’s picture

donquixote commented

Is there an easy one-liner to set this variable to a proper value?

You could do a drush vset xautoload_cache_prefix yasdfsdfafdsa
Not sure if you need quotes or not.

I think I have a solid plan now, and will look to fix this tonight.

fuzzy76’s picture

fuzzy76 commented

On our Aegir setup with a lot of sites per install, this did the trick (for anyone else stumbling upon this):
drush @sites php-eval "variable_set('xautoload_cache_prefix', base64_encode(openssl_random_pseudo_bytes(16)));"

donquixote’s picture

donquixote commented

Easier option:
drush @sites vdel xautoload_cache_prefix
This means it will be recalculated on all sites.