SUPEE-6788 (возможно) проблемы с кешем

С тех пор, как мы применили исправление SUPEE-6788 на сайте клиента, примерно один раз в день сайт выходил из строя, и единственное, что, кажется, возвращает его, - это очистить кеш. Мы просмотрели журналы, и некоторые из них, по-видимому, включают «Фронт-контроллер достиг 100 итераций сопоставления маршрутизаторов». Эта проблема не возникала до применения патча. Кто-нибудь знает, что может быть причиной этого? Некоторые люди говорят, что это может быть ошибка кеша в magento, но я не могу сказать. Любой вклад будет полезен!

Некоторые дополнительные заметки:

• Не было никаких тяжелых нагрузок на сервер, когда он выходит из строя, так что это не фактор.
• Да, все предыдущие исправления были успешно применены.
• Мы используем memcache для хранения кеша.

У меня и другого разработчика возникла похожая проблема, однако мы, похоже, решили ее, применив патч, присутствующий в этом GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

Причина, по-видимому, в каком-то состоянии состязания, когда кэш очищается одним процессом, а другой экземпляр повторно создается, и я смог воспроизвести его, выполнив шаги, также перечисленные на этом GitHub.

Я открыл службу поддержки Magento для этой проблемы, и у меня есть подозрения о том, что стало причиной этого после патча, но я жду ответа.

Вы можете прочитать больше об этом по следующему вопросу: Проблемы с Unstyled Page, Bad Paths, потеря конфигурации макета после применения патча SUPEE-6788 .

У нас та же проблема с 3 сайтами версии 1.8.1. Он начал появляться после SUPEE 6788. Исправление сверху не решило проблему. На самом деле, похоже, есть некоторые изменения. До исправления сайты зависали два раза в день, теперь последний сбой был через 2 дня. Но может быть это связано с нагрузкой. 3 сайта маленькие и не очень загруженные. Эта проблема не возникает с большим сайтом версии 1.6.2 и SUPEE 6788. Все сайты находятся на одном сервере - 3 с версией 1.8.1 и большой с версией 1.6.2

Мы переключили кэш сайта с memcache на Redis, а затем добавили cronjob для сброса кэша каждые 12 часов. Он переходил от сбоя один раз в день к 4-5 дням, прежде чем снова падал. Затем мы настраивали cronjob для сброса каждые 6 часов, и с тех пор он не снижался (с тех пор прошло около 3-4 дней). Ни мы, ни хостинговая компания не можем отследить реальную проблему, но это, похоже, исправление для нас. Надеюсь, что это помогает кому-то.

Я добавил код отладки AmpersandHQ этим утром и только сейчас произвел исключение «Фронтальный контроллер достиг 100 итераций сопоставления маршрутизатора» примерно 75 раз за 2 минуты. Но на этот раз, предположительно из-за того, что код отладки не сохраняет поврежденную запись в кэше, сайт все еще работает, и все не получают исключений (я не очищал кэш).

Я еще не копался в этом, чтобы исследовать, но коррупционный-cache.log содержит:

2015-11-22T03:42:42+00:00 DEBUG (7):
#0 app/code/core/Mage/Core/Model/App.php(1147): Mage_Core_Model_Cache->save('<admin><design>...', 'config_global_s...', Array, NULL)
#1 app/code/core/Mage/Core/Model/Config.php(552): Mage_Core_Model_App->saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#2 app/code/core/Mage/Core/Model/Config.php(474): Mage_Core_Model_Config->_saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#3 app/code/core/Mage/Core/Model/App.php(421): Mage_Core_Model_Config->saveCache()
#4 app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#5 app/Mage.php(683): Mage_Core_Model_App->run(Array)
#6 index.php(87): Mage::run('', 'store')
#7 {main}

Это на Magento 1.7.0.2 с уже установленным кешем Redis и патчем SUPEE-4755 от AmpersandHQ.

Обновление от 2 декабря 2015 г. Вот еще одна ошибка с полной трассировкой стека:

2015-12-02T20:02:27+00:00 DEBUG (7):
#0 app/code/local/Mage/Core/Model/App.php(1156): save('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#1 app/code/local/Mage/Core/Model/Config.php(552): saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#2 app/code/local/Mage/Core/Model/Config.php(474): _saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#3 app/code/local/Mage/Core/Model/App.php(430): saveCache()
#4 app/code/local/Mage/Core/Model/App.php(343): _initModules()
#5 app/Mage.php(683): run(Array)
#6 index.php(87): run('', 'store')

Мы уже несколько недель испытываем ту же проблему с различными веб-сайтами Magento CE. Однако ни одно из размещенных здесь предложений не помогло. После нескольких разочаровывающих отладочных сессий в течение нескольких недель нам наконец-то удалось установить это.

Таким образом, мы обнаружили, что проблема заключается в комбинации патча SUPEE-6788, Magento <1.9.2.0 и PHP> = 5.5.22, с потенциальными злоумышленниками или даже сканерами безопасности, способными блокировать сайты по требованию. Мы разместили полную информацию, включая исправление, в нашем блоге . Я искренне надеюсь, что это поможет любым другим бедным душам, страдающим той же проблемой.

Мы сталкиваемся с этой проблемой и с нашими веб-сайтами с момента выпуска SUPEE6788, и кажется, что мошеннические обращения к веб-сервисам xmlrpc могут быть причиной повреждения кэша.

Мы блокируем вызовы веб-сервисов с наших фронт-серверов, так как мы их не используем + применяем SUPEE 4755, я буду держать вас в курсе.