Ошибка Magento «Фронт-контроллер достиг 100 итераций соответствия маршрутизатора» - PullRequest
26 голосов
/ 07 июня 2011

Мой сайт отключается один или два раза в день, когда он начинает выдавать исключение "Фронт-контроллер достиг 100 итераций сопоставления маршрутизатора". Как только это произойдет, доступ к админке и интерфейсу исчезнет. Я только что оставил страницу с ошибкой.

Это началось после обновления с Magento 1.5.0.1 до 1.5.1.0. Если я вручную очищаю каталог var / cache /, я снова работаю.

Я, черт возьми, гуглил это. В ограниченных результатах поиска я не нашел ничего, что помогло бы мне решить эту проблему.

Любое понимание того, почему это может происходить и как это можно решить, будет оценено.

- обновление -----------------------

Используя отладочный код, предоставленный в полезном ответе от Андрея Церкуса, я смог определить, что ошибка вызвана исчезновением некоторых моих маршрутизаторов.

Обычные маршрутизаторы, выводимые кодом отладки: Всего 7: admin, стандарт, cms, amshopby, fishpig_wordpress, seosuite, по умолчанию

При возникновении ошибки они изменились на: Всего 3: админ, стандарт, по умолчанию

Когда это происходит, кажется, что из-за пропущенных маршрутов код повторяется до 100 для каждого запроса страницы. Я буду исследовать это состояние дальше.

Ответы [ 11 ]

13 голосов
/ 21 января 2015

ОБНОВЛЕНИЕ 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: Обновлено для тестирования на vanilla 1.5

Я только что запустил сценарий репликацииванильная установка 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 действию?

11 голосов
/ 06 июля 2011

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

Как видно из сообщения, проблема возникает из-за того, что ваши маршрутизаторы делают циклические ссылки для отправки запросов. Один из них соответствует запросу, но не отправляет его и не отправляет повторно. Или ни один маршрутизатор не соответствует запросу вообще.

Более подробную информацию вы можете получить, перейдя в файл приложения Magento Core / 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 и посмотрите там отладочную информацию о том, что происходит внутри вашей системы. Это поможет намного лучше увидеть, какой маршрутизатор ломает систему.

6 голосов
/ 01 декабря 2015

Это сообщение вызвано плохими данными конфигурации. Я не уверен, что на самом деле приводит к повреждению кэшированной конфигурации - я думаю, это может быть несколько вещей, которые могут отличаться в зависимости от того, как работает Magento.

Полагаю, если вы все еще можете получить доступ к бэкэнду Magento, вы можете попробовать очистить кеш в разделе Система> Управление кешем. Если это не помогает (или если вы не можете добраться до бэкэнда Magento, что, вероятно, связано с этой ошибкой), то определите, как настроено ваше кэширование, найдя значение в app / 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
3 голосов
/ 13 ноября 2015

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

chmod 770 app / code / core / Mage / Cms / controllers / IndexController.php

Надеюсь, это кому-нибудь поможет.

3 голосов
/ 22 декабря 2011

У нас возникла та же проблема, и мы покопались немного глубже, обнаружив, что проблема не связана напрямую с тем, какие маршрутизаторы загружены, а какие модули загружены.

Для решения этой проблемы мы добавилиследующий код отладки:

    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 (проверьте узел 'config / modules'. Мы думаем, что есть какая-то гонкавозникает условие, которое означает, что в системе остается частично сформированная конфигурация, которая затем кэшируется.

Было бы интересно услышать, если у вас такая же ситуация.

2 голосов
/ 10 ноября 2011

Эта ошибка мучила одного из наших клиентов также при очень высоких нагрузках. Изменение значения URL-адреса администратора в local.xml устранило обе проблемы

1 голос
/ 27 декабря 2014

Это может не помочь вам, но может помочь другим. У меня была та же самая проблема на ровном месте.

Удаление кеша и блокировок вручную решило проблему для меня (на данный момент).

0 голосов
/ 12 февраля 2018

Наконец-то я справился с проблемой, это было связано с сортировкой в ​​etc frontend di.xml <item name="sortOrder" xsi:type="string">20</item>. Я изменил 20 на 60, и ошибка исчезла.

См .: Magento 2.1.2Фабрика действий Роутера заходит в бесконечный цикл

0 голосов
/ 31 мая 2016

Это лучшие шаги для решения проблем такого типа:

  1. Исправление сервера Apache.
  2. Раскомментирование строки из .htaccess, если magento в подкаталоге.
  3. Удаление каталога /var/cache и включение mod_rewrite.
  4. Включить использование HTACCESS.
  5. Создание страницы CMS без маршрута.
  6. Укажите правильную страницу 404.
  7. Не удается найти куки пользователя (возможная причина тоже).

Для получения более подробной информации о реализации вышеуказанных шагов перейдите по этой ссылке ниже: https://merchantprotocol.com/506/solved-front-controller-reached-100-router-match-iterations/

Я бы очень рекомендовал прочитать инструкцию Алана Строма. Ссылка руководства Алана Шторма: http://alanstorm.com/magentos_many_404_pages

0 голосов
/ 14 марта 2016

Возможно, ваше имя администратора не совпадает с roouter-> adminhtml-> frontname в app / etc / local.xml

Перейдите в этот каталог app / etc / local.xml из вашего проекта magento и убедитесь, что он должен совпадать с вашим адресом панели администратора;

<admin>
    <routers>
        <adminhtml>
            <args>
                <frontName><![CDATA[myadminfrontname]]></frontName>
            </args>
        </adminhtml>
    </routers>
</admin>

Ваш URL должен быть таким

http://www.myproject.com/myadminfrontname/

также вы можете удалить каталог кеша с помощью этого кода.

перейдите в корневой каталог вашего проекта и напишите

rm -rfv var/*
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...