Development #14913
La gestion du Timeout générale ne marche pas sur toutes les applis
Statut:
Fermé
Priorité:
Normal
Assigné à:
Josué Kouka
Catégorie:
-
Version cible:
-
Début:
08 février 2017
Echéance:
% réalisé:
100%
Temps estimé:
Patch proposed:
Oui
Planning:
Description
Dans le cas de Ermes (Archimed) il y'a des moments ou l'on a un timeout alors que le processus phantomjs a terminé son job.
Fichiers
Révisions associées
Historique
Mis à jour par Josué Kouka il y a environ 7 ans
- Fichier 0001-improve-generic-timeout-handling-14913.patch 0001-improve-generic-timeout-handling-14913.patch ajouté
- Patch proposed changé de Non à Oui
Mis à jour par Josué Kouka il y a environ 7 ans
Dans tests/settings.py
le PHANTOM_JS_TIMEOUT
est changé parce que signal.alarm
ne prend que des entiers
.
Mis à jour par Frédéric Péters il y a environ 7 ans
Ce serait bien de noter où et pourquoi ça ne fonctionnait pas.
Mis à jour par Josué Kouka il y a environ 7 ans
- Fichier 0001-improve-generic-timeout-handling-14913.patch 0001-improve-generic-timeout-handling-14913.patch ajouté
- Description mis à jour (diff)
Frédéric Péters a écrit :
En cherchant mieux, les raisons pour lesquelles ça ne fonctionne pas sont les suivantes (principalement liées à mon implémentation) :Ce serait bien de noter où et pourquoi ça ne fonctionnait pas.
deadlock
(https://docs.python.org/2.7/library/multiprocessing.html#all-platforms)process.start() process.join(settings.PHANTOM_JS_TIMEOUT) .... result = recv_end.recv()
Bizarrement, quand des infos d'une petite taille sont envoyées via le pipe, il n'y a aucun dysfonctionnement. C'est ce qui m'a induit en erreur.
- dans le
run
, je ne ferme pas le bout du Pipe (send_end
) qui envoie le message (https://docs.python.org/2.7/library/multiprocessing.html#exchanging-objects-between-processes)Note that data in a pipe may become corrupted if two processes (or threads) try to read from or write to the same end of the pipe at the same time. Of course there is no risk of corruption from processes using different ends of the pipe at the same time.
.
Mis à jour par Josué Kouka il y a environ 7 ans
- Fichier 0001-improve-generic-timeout-handling-14913.patch 0001-improve-generic-timeout-handling-14913.patch ajouté
- Utilisation de
connection.poll
pour "timeouter" lesender
vu qu'unprocess.join()
n'a pas d'effet sur unPipe
Mis à jour par Josué Kouka il y a environ 7 ans
- Fichier 0001-improve-generic-timeout-handling-14913.patch 0001-improve-generic-timeout-handling-14913.patch ajouté
Sans modification des tests.
Mis à jour par Josué Kouka il y a environ 7 ans
- Fichier 0001-improve-generic-timeout-handling-14913.patch 0001-improve-generic-timeout-handling-14913.patch ajouté
rebase on master
Mis à jour par Serghei Mihai il y a environ 7 ans
Testé avec Ermes et Teamnet et ça fonctionne même si pour Ermes le timeout de 10 secondes souvent n'est pas suffisant.
Ack.
Mis à jour par Josué Kouka il y a environ 7 ans
- Fichier 0001-improve-generic-timeout-handling-14913.patch 0001-improve-generic-timeout-handling-14913.patch ajouté
- Statut changé de En cours à Résolu (à déployer)
- % réalisé changé de 0 à 100
Ok
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Fermé
improve generic timeout handling (#14913)