Magento "Контроллер фронтального контроллера достиг 100 итераций с использованием маршрутизатора"
Мой сайт падает один или два раза в день, когда он начинает бросать исключение. "Передний контроллер достиг 100 итераций с использованием маршрутизатора". Как только это произойдет, доступ к админу и интерфейсу исчез. Я просто оставил страницу с ошибкой.
Это началось после обновления с Magento 1.5.0.1 до 1.5.1.0. Если я вручную очистит каталог var/cache/, я снова загрузился.
Я выбрал эту черту. В ограниченных результатах поиска я ничего не нашел, помог мне решить это.
Любое понимание того, почему это может происходить и как оно может быть разрешено, будет оценено.
- обновление -----------------------
Используя код отладки, предоставленный в полезном ответе от Андрея Церкуса, я смог определить, что ошибка вызвана тем, что некоторые из моих маршрутизаторов исчезают.
Обычными маршрутизаторами, выводимыми кодом отладки, являются:
Всего 7: admin, standard, cms, amshopby, fishpig_wordpress, seosuite, default
При возникновении ошибки они изменились на:
Всего 3: admin, standard, default
Когда это происходит, кажется, что недостающие маршруты заставляют код итератировать до 100 для каждого запроса страницы. Я исследую это условие далее.
Ответы
Ответ 1
ОБНОВЛЕНИЕ 2: У меня есть некоторые дополнительные изменения, которые должны помочь предотвратить другую причину повторения итераций со 100 маршрутизаторами.
https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements
=============================================== =====================
ОБНОВЛЕНИЕ: MAGENTO ИСПОЛЬЗУЕТ МОЙ ОТВЕТ КАК ПУТЬ
https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-good-news-a-patch-from-magento
=============================================== =====================
Недавно я потратил довольно много времени на изучение этой ошибки. Я написал свои полные результаты, объяснения и репликации здесь.
https://github.com/convenient/magento-ce-ee-config-corruption-bug
Однако для краткого ответа. Это, по-видимому, ошибка Magento, которая может быть исправлена путем переопределения Mage_Core_Model_Config::init
следующим образом:
public function init($options=array())
{
$this->setCacheChecksum(null);
$this->_cacheLoadedSections = array();
$this->setOptions($options);
$this->loadBase();
$cacheLoad = $this->loadModulesCache();
if ($cacheLoad) {
return $this;
}
//100 Router Fix Start
$this->_useCache = false;
//100 Router Fix End
$this->loadModules();
$this->loadDb();
$this->saveCache();
return $this;
}
EDIT: Обновлено для тестирования на ваниле 1.5
Я только что запустил репликацию script на ванильной установке 1.5. У всех кэшей, кроме кэша CONFIG
, отключено.
Он не вызвал ошибку 100 router
, как и в случае с 1.13, но сломал веб-сайт, и вся отображаемая домашняя страница была белым экраном.
Причиной было то, что когда мы искали контроллер и действие, мы сопоставлялись с Mage_Core_IndexController::indexAction
вместо Mage_Cms_IndexController::indexAction
.
class Mage_Core_IndexController extends Mage_Core_Controller_Front_Action {
function indexAction()
{
}
}
Mage_Core_IndexController::indexAction
- это пустая функция, и она отлично иллюстрирует белую страницу.
Я больше не могу реплицировать эту ошибку при размещении _useCache = false
в Mage_Core_Model_Config
.
Я полагаю, что, возможно, уникальная конфигурация ваших сайтов Magento может привести к тому, что он полностью не сможет соответствовать контроллеру, а не возвращаться к этому действию Mage_Core_IndexController
?
Ответ 2
Сообщение об ошибке слишком общее, чтобы попытаться решить эту проблему. Я предлагаю вам нанять веб-разработчика freelancer Magento, чтобы посмотреть на источник проблемы на вашем фактическом сайте. Теоретически он не может быть решен.
Как видно из сообщения, проблема возникает из-за того, что ваши маршрутизаторы создают круговые ссылки для отправки запросов. Один из них соответствует запросу, но не отправляет и не отталкивает его снова для повторной отправки. Или никакой запрос на сопоставление роутера вообще отсутствует.
Вы можете получить дополнительную информацию, перейдя в приложение Magento Core file/code/core/Mage/Core/Controller/Varien/Front.php, найдите там строки
while (!$request->isDispatched() && $i++<100) {
foreach ($this->_routers as $router) {
if ($router->match($this->getRequest())) {
break;
}
}
}
и замените их на
Mage::log('----Matching routers------------------------------');
Mage::log('Total ' . count($this->_routers) . ': ' . implode(', ', array_keys($this->_routers)));
while (!$request->isDispatched() && $i++<100) {
Mage::log('- Iteration ' . $i);
$requestData = array(
'path_info' => $request->getPathInfo(),
'module' => $request->getModuleName(),
'action' => $request->getActionName(),
'controller' => $request->getControllerName(),
'controller_module' => $request->getControllerModule(),
'route' => $request->getRouteName()
);
$st = '';
foreach ($requestData as $key => $val) {
$st .= "[{$key}={$val}]";
}
Mage::log('Request: ' . $st);
foreach ($this->_routers as $name => $router) {
if ($router->match($this->getRequest())) {
Mage::log('Matched by "' . $name . '" router, class ' . get_class($router));
break;
}
}
}
После этого подождите, пока сайт создаст ошибку, откройте файл var/log/system.log и увидите там отладочную информацию о том, что происходит внутри вашей системы. Это поможет увидеть гораздо лучше, что маршрутизатор разбивает систему.
Ответ 3
Это сообщение вызвано плохими кэшированными данными конфигурации. Я не уверен, что на самом деле приводит к повреждению кэшированной конфигурации - я бы предположил, что это может быть ряд вещей, которые могут варьироваться в зависимости от того, как работает Magento.
Я думаю, если вы все еще можете добраться до бэкэнда Magento, вы можете попробовать очистить кеш в System > Cache Management. Если это не помогает (или если вы не можете добраться до бэкэнда Magento, что, вероятно, с этой ошибкой), то определите, как настроено ваше кэширование, найдя значение <cache> <backend> в приложении /etc/local.xml. Если вы используете файлы для кеша (по умолчанию), можете ли вы очистить magento/var/cache с помощью
rm -rf /path/to/magento/var/cache/*
Если вы используете memcached, найдите порт под < порт > , и вы можете сделать
telnet memcache_server portnumber
flush_all
Или, если вы используете redis, вы можете сделать
telnet redis_server portnumber
FLUSHALL
Ответ 4
У нас была одна и та же проблема, и мы немного углубились, обнаружив, что проблема напрямую не связана с загрузкой маршрутизаторов, но какие модули загружаются.
Для этого мы добавили следующий код отладки:
app/code/core/Mage/Core/Controller/Varien/Front.php : Line 183
if ($i>100) {
file_put_contents('/tmp/debug.txt', Mage::getConfig()->getNode()->asNiceXml());
Mage::throwException('Front controller reached 100 router match iterations');
}
Когда мы проверяем вывод этого, мы можем видеть, что ТОЛЬКО загружен модуль Mage_Core (проверьте конфигурацию/модули node '. Мы считаем, что происходит какое-то состояние гонки, которое означает, что система слева с частично сформированной конфигурацией, которая затем кэшируется.
Было бы интересно услышать, если у вас такая же ситуация.
Ответ 5
Эта ошибка преследовала одного из наших клиентов также с очень большими нагрузками. изменение значения URL-адреса администратора в local.xml устраняло обе проблемы.
Ответ 6
Я попробовал все вышеперечисленные предложения и ничего не получил.
Затем я попытался создать резервную копию, так как я собирался попробовать обновление, и я получил ошибку разрешения, читающую файл. Это было довольно странно, поэтому я изменил разрешения, и он сразу начал работать.
chmod 770 app/code/core/Mage/Cms/контроллеры/IndexController.php
Надеюсь, это поможет кому-то.
Ответ 7
Это может не помочь вам, но может помочь другим. У меня была одна и та же проблема с самого начала.
Удаление кеша и блокировок вручную устранило проблему для меня (пока).
Ответ 8
Если Magento отсутствует страница C-страницы без маршрута (URL-адрес ключа no-route
), или если параметр CMS No Route Page
по умолчанию не установлен правильно в System=>Configuration=>Web=>Default Pages
, Magento может перейти в бесконечный цикл, пока он не достигнет 100 предел итераций.
Ответ 9
Вероятно, ваше имя admin не совпадает с roouter- > adminhtml- > frontname в приложении /etc/local.xml
Перейдите в этот каталог app/etc/local.xml из вашего проекта magento и убедитесь, что он должен быть таким же, как и с вашим url-frontname вашей админ-панели;
<admin>
<routers>
<adminhtml>
<args>
<frontName><![CDATA[myadminfrontname]]></frontName>
</args>
</adminhtml>
</routers>
</admin>
Ваш url должен быть таким
http://www.myproject.com/myadminfrontname/
также вы можете удалить каталог кэша с помощью этого кода.
перейдите в корневой каталог проекта и напишите
rm -rfv var/*
Ответ 10
Наконец, я преодолел проблему, это произошло из-за sortorder в etc frontend di.xml <item name="sortOrder" xsi:type="string">20</item>
.I изменилось с 20 на 60, и ошибка исчезла.
См.: Magento 2.1.2. Завод по обработке Rourter попадает в бесконечный цикл
Ответ 11
Это лучшие шаги для решения таких проблем:
- Фиксация сервера Apache.
- Раскомментирование строки из
.htaccess
, если magento в подкаталоге.
- Удаление каталога
/var/cache
и включение mod_rewrite
.
- Включить использование HTACCESS.
- Создайте страницу CMS без маршрута.
- Укажите правильную страницу 404.
- Cant Find User Cookie (возможно, причина).
Подробнее о реализации описанных выше шагов см. ниже:
https://merchantprotocol.com/506/solved-front-controller-reached-100-router-match-iterations/
Я бы тоже рекомендовал прочитать инструкцию Алана Стром.
Ссылка руководства Алана Шторма: http://alanstorm.com/magentos_many_404_pages