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