Bug #18813
Aucune trace reçue sur un gateway 502 lors de la génération d'un document
0%
Description
cf #18604
Fichiers
Historique
Mis à jour par Frédéric Péters il y a plus de 6 ans
Il n'y a pas de trace sur les 502, ce n'est pas wcs qui a la main.
sep 20 12:59:51 auquo-test uwsgi[25662]: [pid: 25685|app: 0|req: 5453/18817] 0.0.0.0 () {48 vars in 997 bytes} [Wed Sep 20 12:59:47 2017] GET /backoffice/management/test_nb-de-pages-conditionne/69/ => generated 8585 bytes in 4117 msecs (HTTP/1.0 200) 4 headers in 152 bytes (1 switches on core 0)
sep 20 13:00:14 auquo-test uwsgi[25662]: Wed Sep 20 13:00:14 2017 - *** HARAKIRI ON WORKER 5 (pid: 31667, try: 1) ***
sep 20 13:00:14 auquo-test uwsgi[25662]: Wed Sep 20 13:00:14 2017 - HARAKIRI !!! worker 5 status !!!
Mis à jour par Thomas Noël il y a plus de 6 ans
- Statut changé de Nouveau à Rejeté
Yep (faudra qu'on se les remonte par un autre moyen, les 502, dans un futur système de log)
Mis à jour par Benjamin Dauvergne il y a plus de 6 ans
- Fichier 0001-export_to_model-set-a-timeout-of-20s-for-running-lib.patch 0001-export_to_model-set-a-timeout-of-20s-for-running-lib.patch ajouté
- Patch proposed changé de Non à Oui
Ça veut surtout dire qu'on doit contrôler le temps prix par LO pour générer un document et abandonner au bout de 20s non ?
Inspiration pour le patch venant de http://www.ostricher.com/2015/01/python-subprocess-with-timeout/ .
Mis à jour par Thomas Noël il y a plus de 6 ans
Benjamin Dauvergne a écrit :
Ça veut surtout dire qu'on doit contrôler le temps prix par LO pour générer un document et abandonner au bout de 20s non ?
Libreoffice ne fait que la partie odt->pdf, c'est la partie odt+formdata->odt qui ramait beaucoup (#18814)
Ça me va de laisser libreoffice prendre son temps : il peut avoir été appelé en dehors d'une requête (via cron, trigger_jumps, etc)
Mis à jour par Benjamin Dauvergne il y a plus de 6 ans
Ça me va si on un contrôle de la durée de traitement des requêtes par ailleurs, #18889.