Fixed Cannot create new style when APC cache is enabled

[Andy Huang]

I'm noticing that I cannot seem to create a new style when I have APC cache enabled.

Error Message:

apc_store(): Potential cache slam averted for key 'xf_data_styles'

1. XenForo_Application::handlePhpError()
2. apc_store()inZend/Cache/Backend/Apc.phpat line112
3. Zend_Cache_Backend_Apc->save()inZend/Cache/Core.phpat line390
4. Zend_Cache_Core->save()inXenForo/Model/DataRegistry.phpat line158
5. XenForo_Model_DataRegistry->set()inXenForo/Model/Style.phpat line388
6. XenForo_Model_Style->rebuildStyleCache()inXenForo/DataWriter/Style.phpat line164
7. XenForo_DataWriter_Style->_rebuildCache()inXenForo/DataWriter/Style.phpat line156
8. XenForo_DataWriter_Style->_postSave()inXenForo/DataWriter.phpat line1291
9. XenForo_DataWriter->save()inXenForo/ControllerAdmin/Style.phpat line99
10. XenForo_ControllerAdmin_Style->actionSave()inXenForo/FrontController.phpat line303
11. XenForo_FrontController->dispatch()inXenForo/FrontController.phpat line132
12. XenForo_FrontController->run()in/home/.../forums/admin.phpat line13

Replication procedures:
1) Enable APC caching
2) Make sure cache is written into APC already (visiting any page should do this)
3) Go Admin CP and try to create a new style

 

[DSF]

I can not reproduce this

 

[Mike]

It looks to be dependent on APC version. It only lets you set a cache value once per script run? That seems really baffling to me.

I can try to workaround it here, but there's no way we could guarantee that it wouldn't happen elsewhere. Seems like a mis-feature to me.

 

[Vladislav Rastrusny]

Andy, what's the APC version?

 

[wwwicked]

I had this problem earlier today, after installing APC last night. It will depend on the version of APC you're running, as I understand (this will probably happen with 3.1.3 or later). The solution that worked for me was adding the following to php.ini:

apc.slam_defense=0

According to the PHP manual, slam_defense is deprecated, but it still seemed to do the trick for me. An alternative would be to use an older version of APC.

 

[Andy Huang]

Andy, what's the APC version?

3.1.4

I had this problem earlier today, after installing APC last night. It will depend on the version of APC you're running, as I understand (this will probably happen with 3.1.3 or later). The solution that worked for me was adding the following to php.ini:

apc.slam_defense=0

According to the PHP manual, slam_defense is deprecated, but it still seemed to do the trick for me. An alternative would be to use an older version of APC.

will give this a try later, thanks!

 

[Scott]

It looks to be dependent on APC version. It only lets you set a cache value once per script run? That seems really baffling to me.

I can try to workaround it here, but there's no way we could guarantee that it wouldn't happen elsewhere. Seems like a mis-feature to me.

It's not per script run but per second, there is a lot of CPU overhead from the shared user cache. It's along the lines of, if you had to set it twice, why not just set it to the end value in the first place.

 

[melbo]

I had the same thing on APC 3.15. I removed APC info from config.php and installed the style fine.

 

[Mike]

I believe I have worked around this particular issue for the next release. It also appears that APC has changed this to not do slam_defence within a process/thread (http://svn.php.net/viewvc/pecl/apc/trunk/apc_cache.c?r1=304338&r2=305258). This isn't in a released version of APC yet, but 3.1.6 should eliminate this issue in the future.