Depuis que nous avons appliqué le correctif SUPEE-6788 sur le site d'un client, environ une fois par jour, le site est en panne et la seule chose qui semble le ramener est de vider le cache. Nous avons examiné les journaux, et un tas d'entre eux semblent inclure "Le contrôleur frontal a atteint 100 itérations de correspondance de routeur". Ce problème ne se produisait pas avant l'application du correctif. Quelqu'un a une idée de ce qui pourrait causer cela? Certaines personnes disent que cela pourrait être un bug de cache dans le problème de magento, mais je ne peux pas le dire. Toute entrée serait utile!
Quelques notes supplémentaires:
- Il n'y a pas eu de lourdes charges sur le serveur au moment où il tombe en panne, donc ce n'est pas un facteur.
- Oui, tous les correctifs précédents ont été appliqués avec succès.
- Nous utilisons memcache pour stocker le cache.
ce-1.8.1.0
Daryl Gochnauer
la source
la source
Réponses:
Moi et un autre développeur avons rencontré un problème similaire, mais nous semblons l'avoir résolu en appliquant le patch présent dans ce GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug
La cause semble être une sorte de condition de concurrence critique où le cache est effacé par un processus tout en étant réinstancié par un autre, j'ai pu le reproduire en suivant les étapes également répertoriées sur ce GitHub.
J'ai ouvert un ticket de support avec Magento pour ce problème et j'ai mes soupçons sur ce qui a commencé à le provoquer depuis le patch, mais j'attends de les entendre.
Vous pouvez en savoir plus à ce sujet sur la question suivante: problèmes avec la page sans style, chemins d'accès incorrects, perte de configuration de la mise en page après l'application du correctif SUPEE-6788 .
la source
Nous avons le même problème avec la version 1.8.1 de 3 sites. Il a commencé à apparaître après SUPEE 6788. Le correctif ci-dessus n'a pas résolu le problème. En fait, il semble qu'il y ait un changement. Avant le correctif, les sites se bloquaient deux fois par jour, maintenant le dernier crash était après 2 jours. Mais c'est peut-être lié à la charge. Les 3 sites sont petits et peu chargés. Ce problème n'apparaît pas avec un grand site qui est la version 1.6.2 et SUPEE 6788 appliqué. Tous les sites sont sur le même serveur - le 3 avec la version 1.8.1 et le grand avec la version 1.6.2
la source
Nous avons fait passer le cache du site de memcache à Redis, puis ajouté un cronjob pour vider le cache toutes les 12 heures. Il est passé de l'écrasement une fois par jour à environ 4-5 jours avant de redescendre. Nous avons ensuite modifié le cronjob pour vider toutes les 6 heures et il n'a pas baissé depuis (cela fait environ 3-4 jours depuis). Ni nous ni la société d'hébergement ne pouvons retrouver le problème réel, mais cela semble être une solution de travail pour nous. J'espère que cela aide quelqu'un.
la source
J'ai ajouté le code de débogage AmpersandHQ ce matin et tout à l'heure, l'exception «Le contrôleur frontal a atteint 100 itérations de correspondance de routeur» s'est produite environ 75 fois en 2 minutes. Mais cette fois, probablement parce que le code de débogage n'a pas enregistré l'entrée de cache corrompue, le site est toujours en place sans que tout le monde ne reçoive d'exceptions (je n'ai pas vidé le cache).
Je n'ai pas encore creusé cela pour enquêter, mais corrupt-cache.log contient:
C'est sur Magento 1.7.0.2 avec le cache Redis et le correctif SUPEE-4755 d'AmpersandHQ déjà appliqué.
Mise à jour du 2 décembre 2015: voici une autre erreur avec la trace de pile complète:
la source
useCache = true
erreur de cache d'objets ou de quelque chose d'autre.Nous rencontrons le même problème depuis des semaines avec divers sites Web Magento CE. Cependant, aucune des suggestions affichées ici n'a aidé. Après plusieurs séances de débogage frustrantes sur plusieurs semaines, nous avons finalement réussi à le déterminer.
En résumé, nous avons constaté que le problème était dû à une combinaison du correctif SUPEE-6788, Magento <1.9.2.0 et PHP> = 5.5.22, avec des attaquants potentiels ou même des scanners de sécurité capables de supprimer les sites à la demande. Nous avons publié tous les détails, y compris un correctif, sur notre blog . J'espère vraiment que cela aidera toutes les autres pauvres âmes souffrant du même problème.
la source
Nous rencontrons ce problème et nos sites Web depuis la publication de SUPEE6788 et il semble que les appels frauduleux aux services Web xmlrpc pourraient être responsables de la corruption du cache.
Nous bloquons les appels de service Web de nos serveurs frontaux car nous ne les utilisons pas + en appliquant SUPEE 4755, je vous tiendrai au courant.
la source
libxml_disable_entity_loader
ce qui n'est pas sûr pour les threads. Dans certains cas, cela peut entraîner la redirection de Magento vers la page d'installation, mais je pense qu'il est également possible qu'avant des erreurs comme celle-ci, il manque l'étape loadDB de la génération de configuration, enregistrant les données corrompues dans le cache. Voir magento.stackexchange.com/questions/30071/…