Projet

Général

Profil

Bug #13056

wcs down → échec à récup du thème dans authentic

Ajouté par Frédéric Péters il y a plus de 7 ans. Mis à jour il y a plus d'un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
05 septembre 2016
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non
Club:
Non

Description

Lors du plantage de ce matin, il y a eu des traces comme quoi authentic n'arrivait pas à récupérer le thème. (mais normalement combo fonctionnait et du coup cette erreur n'aurait pas dû être là.

Historique

#1

Mis à jour par Benjamin Dauvergne il y a plus de 7 ans

  • Statut changé de Nouveau à Fermé

Il n'y a pas que w.c.s qui était dans les choux:

combo:/var/log/nginx# grep " 504 " *access.log  |wc
   1400   28995  456364
chateauroux-metropole.fr-access.log:5.135.221.17 - - [05/Sep/2016:08:56:54 +0200] "GET /__skeleton__/?source=https%3A%2F%2Fconnexion.chateauroux-metropole.fr%2Faccounts%2Factivate%2FeyJlbWFpbCI6InJfbmluaWtAeWFob28uZnIiLCJuZXh0IjoiL2lkcC9zYW1sMi9jb250aW51ZT9ub25jZT1fMjEyN0M5QkUzQ0YyMTg4NjJFRDI0NjkzRkQwOTRCQzkifQ%3A1bgn4j%3Akwg7rfFbMtnGvjixkEcgNU8-o8Q%2F HTTP/1.1" 504 176 "-" "python-requests/2.3.0 CPython/2.7.3 Linux/2.6.32-37-pve" 
#2

Mis à jour par Frédéric Péters il y a plus de 7 ans

  • Statut changé de Fermé à Nouveau

Oui, nécessairement vu l'erreur mentionnée dans ce ticket; mais c'est la cascade d'échecs qui m'intéresse ici. Le combo était par lui-même down, ou était down parce que bloqué sur des requêtes vers le wcs lui-même down, etc.

#3

Mis à jour par Benjamin Dauvergne il y a plus de 7 ans

La question c'est plutôt pourquoi il y a tellement de récupération du thème et ensuite est-ce que ça a un effet significatif du coté des applications ou est-ce qu'elles se débrouillent pour utiliser ce qu'elles ont déjà en cache ?

Après oui il y a eu trop de requêtes, comme il n'y a que 5 workers synchrones ça va vite, bloqué par w.c.s. ou pas (mais c'est sûr que ça joue).

On a même des 504 sur de la résolution d'artefact (bloqué par authentic, ou simplement pas assez de worker coté combo...).

On a même du 502 et là je ne sais pas trop ce que c'est:

[05/Sep/2016:08:14:51 +0200] "GET /ajax/cell/7/wcs_wcscurrentformscell-1/ HTTP/1.1" 502 568 "https://citoyen.chateauroux-metropole.fr/ma-situation/demandes/" "Mozilla/5.0 (Wind
ows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586" 

Quand je filtre les logs sur 'ajax' on voit que jusqu'à 8h11 les récupérations de cellules w.c.s. fonctionnent bien mais ensuite à mesure je suppose que les gens commence à utiliser w.c.s. on voit apparaître des 502/504 en pagaille parce que, je suppose, w.c.s. n'arrive pas à suivre et donc ça bloquerait tout le reste.

Je dirais qu'on pourrait mettre un timeout à 5s sur la récupération des catégories ou des listes de formulaires ou de demandes en cours et si ça ne marche pas on renvoie une erreur et on attend un rechargement automatique par la cellule ajax qui devra faire des essaies avec un temps d'attente exponentiel.

#4

Mis à jour par Thomas Noël il y a plus de 7 ans

Même analyse que Benjamin de mon côté (w.c.s. qui finit par bloquer "tout").

Cependant, on ne peut pas généraliser un timeout de façon générique sur toutes les cellules ajax : il y a des cellules qui peuvent mettre plus de 5s à répondre (typiquement lors d'appel ws sur des tiers, j'ai déjà vu du 10s).

#5

Mis à jour par Benjamin Dauvergne il y a plus de 7 ans

Mon idée c'était que la vue ajax sache retourner un message "retry", ensuite le timeout on le met dans l'appel request qui est dans la cellule w.c.s. pas génériquement sur toutes les cellules.

#6

Mis à jour par Frédéric Péters il y a plus d'un an

  • Statut changé de Nouveau à Fermé
  • Planning mis à Non
  • Club mis à Non

(obsolète)

Formats disponibles : Atom PDF