cache:flush doesn't clear config XML using Redis

[robbieaverill]

Hi guys,

I'm running an installation which uses Redis for backend cache and for sessions. I recently had an issue where I had removed a module, including a core model rewrite, and when trying to load certain parts of Magento (credit memos specifically) it would throw an exception screen saying that "Total model should be extended from Mage_Sales_Model_Order_Total_Abstract".

var/cache was empty (as expected since we use Redis) and nothing relevant in the /tmp directory of the server mattered.

I had restarted nginx and php-fpm as well as running n98-magerun.phar cache:clean and cache:flush, and was still experiencing the issue.

If I ran n98-magerun.phar config:dump | grep My_Custom_Class_Override I could still see that the config I had removed was in the merged config XML.

When I manually cleared Redis from the command line i.e. redis-cli -h path-to-host.com -p 6380 flushall it reset correctly.

Does the cache:flush command either not handle Redis or not clear the config cache?

Thanks, Robbie

[ktomk]

583 comes to mind, you perhaps find some hints in there. I would go through this with a debugger, Magento has some multi-stage config/cache/init/clear code, but I don't have the problem right now (nor a box with redis).

[robbieaverill]

Closing as cannot reproduce any longer.

[seansan]

Until it happens again. We haven't had this for months and then suddenly this morning again. Same set-up as your description

[ktomk]

@seansan: Please raise your voice / provide a PR / help with testing / any other kind of contribution in upstream.

It has been as well reported in upstream already https://github.com/GordonLesti/Lesti_Fpc/issues/250 (via: https://github.com/netz98/n98-magerun/issues/775)

While we could probably provide some workaround within Magerun, this would be wrong to do because the root-cause lies within Lesti FPC and it's the perfect place to solve this with a single or only some lines of code in a stable manner. Much better we could ever do from within N98-Magerun.

Please review the issue there and consider how you can make a difference. Let me know if I can be of any help with that.

[seansan]

Thanks: but we dont use Lesti FPC

We just use REDIS ... and also I'd just like to confirm that we have also seen this issue

On Thu, Aug 18, 2016 at 11:43 PM, Tom Klingenberg notifications@github.com wrote:

@seansan https://github.com/seansan: Please raise your voice / provide a PR / help with testing / any other kind of contribution in upstream.

It has been as well reported in upstream already GordonLesti/Lesti_Fpc#250 https://github.com/GordonLesti/Lesti_Fpc/issues/250 (via: #775 https://github.com/netz98/n98-magerun/issues/775)

While we could probably provide some workaround within Magerun, this would be wrong to do because the root-cause lies within Lesti FPC and it's the perfect place to solve this with a single or only some lines of code in a stable manner. Much better we could ever do from within N98-Magerun.

Please review the issue there and consider how you can make a difference. Let me know if I can be of any help with that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/netz98/n98-magerun/issues/754#issuecomment-240866488, or mute the thread https://github.com/notifications/unsubscribe-auth/AAn0a0rGq8ja4y6bwSKNO5BpB9AaHNwcks5qhNHxgaJpZM4HEbT6 .

[tkn98]

Okay, have you tried to flush it two times after another?

[seansan]

Our problem is "more" related to #583 - I now see these 2 are linked. But are root cause matches the other case more. I've also been reading this https://github.com/convenient/magento-ce-ee-config-corruption-bug - but the fix mentioned there also does not solve it. So I must say I am no longer certain what exactly is leading to the 'Front controller reached 100 router match iterations' warning

[tkn98]

I suspect this has core implication. Maybe some initialization order issue. Is it the case you've got the config cache with a redis backend?

[seansan]

Yes we use redis: cache+session

[tkn98]

@seansan: Just asking for clarification: Do you know if it is possible to use different backends for cache? I always suspected this was the case (but I for sure might be wrong on this), but for your report it's important I know about your current awareness/state of information.

[seansan]

Do you know if it is possible to use different backends for cache?

Do you mean switching from / to other storage? Of course we can switch back to /var/ file storage ...

On Mon, Aug 22, 2016 at 9:26 AM, Tom Klingenberg notifications@github.com wrote:

@seansan https://github.com/seansan: Just asking for clarification: Do you know if it is possible to use different backends for cache? I always suspected this was the case (but I for sure ight be wrong on this), but for your report it's important I know about your current awareness/state of information.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/netz98/n98-magerun/issues/754#issuecomment-241333509, or mute the thread https://github.com/notifications/unsubscribe-auth/AAn0a7EiJl9HD8_B13na9DOgbY9p3QF-ks5qiU81gaJpZM4HEbT6 .

[tkn98]

No I meant more, that for config cache use redis backend, for fpc use file etc. So that we have the scenario that config-cache does use the default file-backend in the end while all caches are configured to use redis but at that time config cache does not yet know it's the redis backend.

[ktomk]

Must not be this issue, but some folks were happy while using redis to make use of a new flag in #850. So at least leaving a cross-reference here.