Magento "Front controller reached 100 router match iterations" error

Question

My site is going down once or twice a day when it starts throwing the exception "Front controller reached 100 router match iterations". Once this happens access to the admin and frontend is gone. I am just left with an error page.

This started after upgrading from Magento 1.5.0.1 to 1.5.1.0. If I manually clear the var/cache/ directory I am up and running again.

I have googled the heck out of this one. In the limited search results I have found nothing has helped me with resolving this.

Any insight into why this may be happening and how it could be resolved would be appreciated.

--update-----------------------

Using the debugging code provided in the helpful answer from, Andrey Tserkus, I was able to determine that the error is caused by some of my routers disappearing.

The normal routers output by the debug code are: Total 7: admin, standard, cms, amshopby, fishpig_wordpress, seosuite, default

When the error occurs they have changed to: Total 3: admin, standard, default

When this happens it seems the missing routes causes the code to iterate to 100 for every page request. I will investigate this condition further.

Isn't there anything in the logs (magento's and the server's one)? Just to have an idea where to look to. — OSdave, Jun 07 '11 at 08:54
Have you tried Backup Database, then repair and optimize tables? Also what caching are you using in your local.xml? I'm assuming the file system? — B00MER, Jun 07 '11 at 16:28
Just to give you some more insight - /Mage/Core/Controller/Varien/Front.php has the Exception error. — B00MER, Jun 07 '11 at 16:29
OSdave -- Here is the error. a:5:{i:0;s:52:"Front controller reached 100 router match iterations";i:1;s:473:"#0 app/code/core/Mage/Core/Controller/Varien/Front.php(183): Mage::throwException('Front controlle...') #1 /app/code/core/Mage/Core/Model/App.php(340): Mage_Core_Controller_Varien_Front->dispatch() #2 /app/Mage.php(627): Mage_Core_Model_App->run(Array) #3 /httpdocs/index.php(84): Mage::run('', 'store') #4 {main}";s:3:"url";s:192:"/catalog/product_compare/add/product/12609/... — Christian, Jun 07 '11 at 19:03
B00MER -- I may try to optimize and repair tables at another time. Don't want to mess with that during prime shopping hours. FYI, only one table had any overhead (catalogfullsearch_text) and I optimized that single table. — Christian, Jun 07 '11 at 19:24

Luke Rodgers · Answer 1 · 2016-01-29T15:27:05.803

UPDATE 2: I have some further changes which should help prevent a different cause of the 100 router match iterations

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

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

UPDATE: MAGENTO HAVE USED MY ANSWER AS A PATCH

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

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

I've recently spent quite some time looking into this bug. I've written up my full findings, explanation and replication here.

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

However, for the short answer. This appears to be a Magento bug which can be corrected by overriding Mage_Core_Model_Config::init with the following:

 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: Updated to test on vanilla 1.5

I just ran the replication script on a vanilla install of 1.5. Which had all caches except for the CONFIG cache disabled.

It did not produce the 100 router error as it does on 1.13, but it did break the website and all the homepage displayed was a white screen.

The cause was that when we were looking for a controller and action we were matched with Mage_Core_IndexController::indexAction instead of Mage_Cms_IndexController::indexAction.

class Mage_Core_IndexController extends Mage_Core_Controller_Front_Action {

    function indexAction()
    {

    }
}

Mage_Core_IndexController::indexAction is an empty function, and explains the white page perfectly.

I can no longer replicate this error when placing _useCache = false into Mage_Core_Model_Config.

I believe that maybe your Magento sites unique configuration might cause it to completely fail to match a controller, as opposed to falling back to this Mage_Core_IndexController action?

I am using an older version (1.5) of Magento and your 100-routers file does not cause the router issue. I still have implemented your fix and will report back if it works or not. Like with you it only happens when the server is under a heavy load. — Christian, Jan 22 '15 at 00:41
Thanks for the edit regarding 1.5. Its seems the problem still persists for me even with your code update. When this error happens the entire site just ends up at an exception alert page. I may try just clearing the cache programmatically when the 100 router exception is thrown. That may limit its impact and allow me to keep the cache enabled. — Christian, Jan 23 '15 at 00:55
Interesting. I was theorising that it would be possible for different scenarios to cause the `100 router` problem but I was never able to figure out different means of causing it. If you implement the hack [here](https://github.com/convenient/magento-ce-ee-config-corruption-bug#debugging-the-issue) you should be able to log a stack trace, and stop the corrupted `CONFIG` cache being saved. If this doesn't catch it, then your malformed config was very different from mine! — Luke Rodgers, Jan 23 '15 at 08:18
Detailed report: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug — Paul Hachmang, Mar 20 '15 at 14:53

score 12 · Answer 2 · answered Jul 06 '11 at 12:53

The error message is too general to try to solve this problem. I suggest you to hire some freelancer Magento web-developer to look to the source of the problem on your actual site. It cannot be solved theoretically.

As seen from the message, the problem occurs because your routers are making circular references for dispatching requests. One of them matches request, but doesn't dispatch and pushes it to redispatch again. Or no router matches request at all.

You can get more information by going to Magento Core file app/code/core/Mage/Core/Controller/Varien/Front.php, find there lines

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

and replace them with

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

After that wait for site to produce the error, open var/log/system.log and see there debugging information about what is going on inside your system. It will help to see much more better, what router breaks the system.

Thank you for the practical suggestion. I will implement this and report back my findings. — Christian, Jul 07 '11 at 07:10
Thanks also that's very helpful. I have a question, I noticed that after it captured some requests, i noticed that there are requests that have empty [module=] Is this normal? — rclai, Aug 13 '14 at 23:34
May I suggest an edit to encourage the OP to revert the core file to the original once the issue is solved? Core files shouldn't remain edited... — tjons, Feb 29 '16 at 14:57

score 6 · Answer 3 · answered Dec 01 '15 at 04:59

This message is caused by bad cached config data. I'm not sure what actually causes the cached config to become corrupted - I would guess it could be a number of things that would vary depending on how Magento is running.

I guess, if you can still get to the Magento backend, you can trying clearing cache under System > Cache Management. If that doesn't help (or if you can't get to the Magento backend, which is likely with this error), then determine how your caching is set up by finding the value of < cache >< backend > in app/etc/local.xml. If you're using files for cache (the default), can you can clear out magento/var/cache with

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

If you're using memcached, find the port under < port > and you can do

telnet memcache_server portnumber
flush_all

Or if you're using redis, you can do

telnet redis_server portnumber
FLUSHALL

score 3 · Answer 4 · answered Nov 13 '15 at 02:20

3

I tried all of the above suggestions, and didnt get anywhere. I then attempted a backup, as I was going to try an upgrade, and I got a permission error reading a file. This was pretty strange, so I changed the permissions, and it instantly started working.

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

Hope this helps someone.

answered Nov 13 '15 at 02:20

Jucks

400
4
10

If the CMS subsystem becomes unavailable for any reason and there is no router match, Magento goes into an infinite loop which is stopped by the 100 iterations rule because there is no default route and Magento cannot find its internal 404 page. This condition is also caused by configuration cache corruption (faulty APC, redis and memcache setups). Bad permissions on the CMS index controller would do it quite well. – Fiasco Labs Dec 10 '15 at 06:32
Just amazed. I tried everything!!!! code etc. and always overlooked this anwer because *we dont have chmod issues* ... but I saw all was 644 instead of 775 ... which is very strange because this is the ONLY directory that has it ... very strange .... major thanks!11! (and now hope it does not occur again) – snh_nl Aug 15 '16 at 15:31
Tried every thing above, none of them work, this comment helped. There was just this file having permission 000, corrected it and worked like charm. Thanks :) – Mounish Ambaliya Oct 17 '18 at 10:35

score 3 · Answer 5 · answered Dec 22 '11 at 16:01

We've been having the same issue, and dug a little deeper to discover that the issue doesn't directly relate to which routers are loaded but which modules are loaded.

To work this out we added the following debug code:

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

When we check the output of this, we can see that ONLY the Mage_Core module is loaded (check the node 'config/modules'. We think there is some kind of race condition that is occuring that means the system is left with a partially formed config that is then cached.

Would be interested in hearing if you have the same situation.

score 2 · Answer 6 · answered Nov 10 '11 at 00:26

2

This error was plaguing one of our clients also with very high loads.. changing the admin url value in local.xml fixed both problems

answered Nov 10 '11 at 00:26

Andy

378
2
8

The error always appeared after visiting the admin at our store. So I tried this and it "solved" the problem. – i.amniels Dec 07 '14 at 15:50

score 1 · Answer 7 · answered Dec 27 '14 at 12:41

1

This might not help you, but might help others. I was having the same problem out of the blue.

Removing the cache and locks manually did resolve the issue for me (for now).

answered Dec 27 '14 at 12:41

Mathijs Segers

6,168
9
51
75

score 0 · Answer 8 · answered Dec 10 '15 at 06:42

0

If Magento is missing the No-Route CMS Page (url key no-route) or if the default CMS No Route Page setting isn't set properly in System=>Configuration=>Web=>Default Pages, Magento can go into an infinite loop till it hits the 100 iterations limit.

answered Dec 10 '15 at 06:42

Fiasco Labs

6,457
3
32
43

score 0 · Answer 9 · answered Mar 14 '16 at 14:58

Probably your admin frontname doesnt match with roouter->adminhtml->frontname in app/etc/local.xml

Go to this directory app/etc/local.xml from your magento project and be sure it must be same with your admin panel url-frontname;

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

Your url must be like this

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

also you can remove your cache directory with this code.

go to your project root directory and write

rm -rfv var/*

score 0 · Answer 10 · answered Feb 12 '18 at 14:34

0

Finally I get over the issue, it was due to sortorder in etc frontend di.xml <item name="sortOrder" xsi:type="string">20</item> .I changed 20 to 60 and the error disappeared.

See: Magento 2.1.2 Rourter action factory gets in to an infinite loop

answered Feb 12 '18 at 14:34

Ionut Florea Dicu

41
5

Magento "Front controller reached 100 router match iterations" error

10 Answers10

Linked