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
Comment #2
donquixote CreditAttribution: donquixote commentedCould 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.
Comment #3
donquixote CreditAttribution: donquixote commentedHm, I think this is a dead end. I am still looking.
Also check #2627228: Clear caches
Comment #4
donquixote CreditAttribution: donquixote commentedCan you compare the value of variable_get('xautoload_cache_prefix') on both sites?
Comment #5
mikemadison CreditAttribution: mikemadison at Pacific Northwest National Laboratory commentedThanks 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.
Comment #6
donquixote CreditAttribution: donquixote commentedOk.
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.
Comment #7
donquixote CreditAttribution: donquixote commentedComment #8
donquixote CreditAttribution: donquixote commentedPlease have a look at comment #8 in #2627228-8: Clear caches
I close this one as duplicate, because it is really the same problem.
Comment #9
mikemadison CreditAttribution: mikemadison at Pacific Northwest National Laboratory commentedwill keep an eye on it. thanks!
Comment #10
fuzzy76 CreditAttribution: fuzzy76 commentedWe 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...
Comment #11
donquixote CreditAttribution: donquixote commentedYou 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.
Comment #12
fuzzy76 CreditAttribution: fuzzy76 commentedOn 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)));"
Comment #13
donquixote CreditAttribution: donquixote commentedEasier option:
drush @sites vdel xautoload_cache_prefix
This means it will be recalculated on all sites.