С тех пор, как мы применили исправление SUPEE-6788 на сайте клиента, примерно один раз в день сайт выходил из строя, и единственное, что, кажется, возвращает его, - это очистить кеш. Мы просмотрели журналы, и некоторые из них, по-видимому, включают «Фронт-контроллер достиг 100 итераций сопоставления маршрутизаторов». Эта проблема не возникала до применения патча. Кто-нибудь знает, что может быть причиной этого? Некоторые люди говорят, что это может быть ошибка кеша в magento, но я не могу сказать. Любой вклад будет полезен!
Некоторые дополнительные заметки:
- Не было никаких тяжелых нагрузок на сервер, когда он выходит из строя, так что это не фактор.
- Да, все предыдущие исправления были успешно применены.
- Мы используем memcache для хранения кеша.
ce-1.8.1.0
Дэрил Гохнауэр
источник
источник
Ответы:
У меня и другого разработчика возникла похожая проблема, однако мы, похоже, решили ее, применив патч, присутствующий в этом 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 содержит:
Это на Magento 1.7.0.2 с уже установленным кешем Redis и патчем SUPEE-4755 от AmpersandHQ.
Обновление от 2 декабря 2015 г. Вот еще одна ошибка с полной трассировкой стека:
источник
useCache = true
ошибкой объектного кэша или чем-то еще полностью.Мы уже несколько недель испытываем ту же проблему с различными веб-сайтами Magento CE. Однако ни одно из размещенных здесь предложений не помогло. После нескольких разочаровывающих отладочных сессий в течение нескольких недель нам наконец-то удалось установить это.
Таким образом, мы обнаружили, что проблема заключается в комбинации патча SUPEE-6788, Magento <1.9.2.0 и PHP> = 5.5.22, с потенциальными злоумышленниками или даже сканерами безопасности, способными блокировать сайты по требованию. Мы разместили полную информацию, включая исправление, в нашем блоге . Я искренне надеюсь, что это поможет любым другим бедным душам, страдающим той же проблемой.
источник
Мы сталкиваемся с этой проблемой и с нашими веб-сайтами с момента выпуска SUPEE6788, и кажется, что мошеннические обращения к веб-сервисам xmlrpc могут быть причиной повреждения кэша.
Мы блокируем вызовы веб-сервисов с наших фронт-серверов, так как мы их не используем + применяем SUPEE 4755, я буду держать вас в курсе.
источник
libxml_disable_entity_loader
что не является потокобезопасным. В некоторых случаях это может привести к перенаправлению Magento на страницу установки, однако я полагаю, что перед такими ошибками также возможно, что он пропустит шаг loadDB генерации конфигурации, сохраняя поврежденные данные в кеше. См. Magento.stackexchange.com/questions/30071/…