web-dev-qa-db-fra.com

Erreur Magento "Le contrôleur frontal a atteint 100 itérations de correspondance de routeur"

Mon site est en panne une ou deux fois par jour lorsqu'il commence à générer l'exception "Le contrôleur frontal a atteint 100 itérations de correspondance de routeur". Une fois que cela se produit, l'accès à l'administrateur et l'interface est parti. Il ne me reste qu'une page d'erreur.

Cela a commencé après la mise à niveau de Magento 1.5.0.1 à 1.5.1.0. Si j'efface manuellement le répertoire var/cache /, je suis à nouveau opérationnel.

J'ai googlé le diable de celui-ci. Dans les résultats de recherche limités, rien ne m'a aidé à résoudre ce problème.

Toute idée de la raison pour laquelle cela pourrait se produire et de la façon dont cela pourrait être résolu serait appréciée.

--mettre à jour-----------------------

En utilisant le code de débogage fourni dans la réponse utile de Andrey Tserkus, j'ai pu déterminer que l'erreur était provoquée par la disparition de certains de mes routeurs. 

Les routeurs normaux générés par le code de débogage sont les suivants: Total 7: admin, standard, cms, amshopby, fishpig_wordpress, seosuite, défaut

Lorsque l'erreur se produit, ils sont remplacés par: Total 3: admin, standard, default

Lorsque cela se produit, il semble que les routes manquantes entraînent une itération du code jusqu'à 100 pour chaque demande de page. Je vais étudier cette condition plus loin.

exceptionmagento
25
Christian

MISE À JOUR 2: J'ai d'autres modifications qui devraient aider à éviter une cause différente des itérations de correspondance du routeur 100

https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements

=============================================== ===================

MISE À JOUR: MAGENTO A UTILISÉ MA RÉPONSE COMME UN PATCH

https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-good-news-a-patch-from-magento

=============================================== ===================

J'ai récemment passé pas mal de temps à examiner ce bogue. J'ai écrit toutes mes conclusions, explications et réplications ici .

https://github.com/convenient/magento-ce-ee-config-corruption-bug

Cependant, pour la réponse courte. Cela semble être un bogue de Magento qui peut être corrigé en surchargeant Mage_Core_Model_Config::init par ce qui suit:

 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: mis à jour pour tester sur Vanilla 1.5

Je viens d'exécuter le script de réplication sur une installation 1.5 de Vanilla. Tous les caches, à l'exception du cache CONFIG, étaient désactivés.

Il n’a pas généré l’erreur 100 router comme c’est le cas pour la version 1.13, mais cela a cassé le site Web et toute la page d’accueil affichée était un écran blanc.

La cause en était que lorsque nous recherchions un contrôleur et une action, nous avons été jumelés avec Mage_Core_IndexController::indexAction au lieu de Mage_Cms_IndexController::indexAction.

class Mage_Core_IndexController extends Mage_Core_Controller_Front_Action {

    function indexAction()
    {

    }
}

Mage_Core_IndexController::indexAction est une fonction vide et explique parfaitement la page blanche. 

Je ne peux plus reproduire cette erreur lorsque je place _useCache = false dans Mage_Core_Model_Config.

Je pense que la configuration unique de vos sites Magento pourrait peut-être empêcher complètement le contrôleur de correspondre à un contrôleur, au lieu de revenir à cette action Mage_Core_IndexController?

12
Luke Rodgers

Le message d'erreur est trop général pour tenter de résoudre ce problème. Je vous suggère de faire appel à un développeur web indépendant Magento pour rechercher la source du problème sur votre site actuel. Cela ne peut pas être résolu théoriquement.

Comme le montre le message, le problème se produit car vos routeurs font des références circulaires pour la distribution des demandes. L'un d'eux correspond à la demande, mais ne l'envoie pas et le pousse à redistribuer à nouveau. Ou aucun routeur ne correspond à la demande du tout.

Vous pouvez obtenir plus d'informations en allant dans le fichier Magento Core app/code/core/Mage/Core/Controller/Varien/Front.php. 

while (!$request->isDispatched() && $i++<100) {
    foreach ($this->_routers as $router) {
        if ($router->match($this->getRequest())) {
            break;
        }
    }
}

et les remplacer par

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;
        }
    }
}

Après avoir attendu que le site génère l’erreur, ouvrez var/log/system.log et consultez les informations de débogage sur ce qui se passe dans votre système. Il sera utile de voir beaucoup mieux, quel routeur casse le système.

11
Andrey Tserkus

Ce message est dû à de mauvaises données de configuration mises en cache. Je ne sais pas vraiment ce qui cause la corruption de la configuration en cache. J'imagine que cela pourrait être dû à un certain nombre d'éléments qui pourraient varier en fonction de la manière dont Magento fonctionne.

J'imagine que si vous pouvez toujours accéder au back-end de Magento, vous pouvez essayer d'effacer le cache sous Système> Gestion du cache. Si cela ne vous aide pas (ou si vous ne parvenez pas à accéder au backend de Magento, ce qui est probablement le cas de cette erreur), déterminez comment votre cache est configuré en recherchant la valeur de <cache> <backend> dans app/etc. /local.xml. Si vous utilisez des fichiers pour le cache (par défaut), pouvez-vous effacer magento/var/cache avec

rm -rf /path/to/magento/var/cache/*

Si vous utilisez memcached, recherchez le port sous <port> et vous pourrez le faire.

telnet memcache_server portnumber
flush_all

Ou si vous utilisez Redis, vous pouvez faire

telnet redis_server portnumber
FLUSHALL
6
siliconrockstar

Nous avons eu le même problème et nous avons creusé un peu plus profondément pour découvrir qu'il n'était pas directement lié aux routeurs chargés mais aux modules chargés.

Pour résoudre ce problème, nous avons ajouté le code de débogage suivant:

    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');
    }

Lorsque nous vérifions la sortie de ceci, nous pouvons voir que SEUL le module Mage_Core est chargé (vérifiez le noeud 'config/modules'. Nous pensons qu'il existe une sorte de condition de concurrence qui se produit, ce qui signifie que le système reste partiellement formé. config qui est ensuite mis en cache.

Serait intéressé à entendre si vous avez la même situation.

3
Peter O'Callaghan

J'ai essayé toutes les suggestions ci-dessus et je ne me suis rendu nulle part .. J'ai ensuite tenté une sauvegarde, car j'allais essayer une mise à niveau et j'ai obtenu une erreur d'autorisation lors de la lecture d'un fichier. C'était assez étrange, alors j'ai changé les permissions et ça a immédiatement commencé à fonctionner.

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

J'espère que ça aide quelqu'un.

3
Jucks

Cette erreur affectait également un de nos clients avec des charges très élevées. La modification de la valeur de l'adresse URL de l'administrateur dans local.xml a résolu les deux problèmes.

2
Andy

Cela pourrait ne pas vous aider, mais pourrait aider les autres. J'avais le même problème à l'improviste.

La suppression manuelle du cache et des verrous a résolu le problème pour moi (pour le moment).

1
Mathijs Segers

Enfin, j’ai surmonté le problème, c’est en raison d’un ordre de tri dans le frontal, etc. di.xml <item name="sortOrder" xsi:type="string">20</item> .J'ai changé 20 à 60 et l’erreur a disparu.

Voir: Magento 2.1.2 La fabrique d’actions Rourter passe à une boucle infinie

0
Ionut Florea Dicu

Si Magento n'a pas la page CMS No-Route (clé URL no-route) ou si le paramètre par défaut CMS No Route Page n'est pas défini correctement dans System=>Configuration=>Web=>Default Pages, Magento peut passer dans une boucle infinie jusqu'à atteindre la limite des 100 itérations.

0
Fiasco Labs

Votre nom admin frontname ne correspond probablement pas à roouter-> adminhtml-> frontname in app/etc/local.xml

Allez dans ce répertoire app/etc/local.xml à partir de votre projet magento et assurez-vous qu'il doit être identique à votre panneau d'administration url-frontname;

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

Votre URL doit être comme ça 

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

vous pouvez aussi supprimer votre répertoire de cache avec ce code.

allez dans le répertoire racine de votre projet et écrivez

rm -rfv var/*
0
fthopkins