Project

General

Profile

Development #67215

Timeout manquant lors de requêtes vers des services extérieurs

Added by Pierre Ducroquet 7 months ago. Updated 7 months ago.

Status:
Information nécessaire
Priority:
Normal
Target version:
-
Start date:
11 July 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Ce matin, on avait 50 connexions SQL empilées à cause de 50 cron hourly combo empilés.
Outre le fait qu'un passage à des crons avec un lock ferait du bien pour éviter cette situation, j'ai noté que le premier cron bloqué (qui bloquait les suivants avec sa transaction) était bloqué sur un read sur une socket ouverte vers une IP extérieure, port 443.
Toutes les requêtes HTTP réalisées dans combo ne se font pas avec un timeout. Par exemple un seul des requests.get de apps/lingo/models.py passe le paramètre timeout.
Du coup, on peut facilement, au moindre coup de vent sur le réseau, se retrouver avec un cron bloqué et les suivants qui vont s'accumuler.

History

#2

Updated by Benjamin Dauvergne 7 months ago

  • Status changed from Nouveau to Information nécessaire
  • Assignee set to Pierre Ducroquet

Il y a un timeout par défaut qui s'applique à 28 secondes (et tous les appels utilisent le wrapper autour de python-requests dans combo.utils.requests_wrapper) :

bdauvergne@revestel:~/wd/eo/combo$ git grep -n REQUESTS_TIMEOUT
combo/data/models.py:1762:                timeout=settings.REQUESTS_TIMEOUT,
combo/settings.py:310:REQUESTS_TIMEOUT = 28
combo/utils/requests_wrapper.py:134:        kwargs['timeout'] = kwargs.get('timeout') or settings.REQUESTS_TIMEOUT

À ce titre la ligne dans combo/data/models.py semble superflue.

#3

Updated by Benjamin Dauvergne 7 months ago

Après vérification la ligne pointée utilise directement python-requests, d'où le besoin de passer explicitement timeout, il y a une deuxième utilisation directe de requests dans la cellule RSS (FeedCell) dont je ne pense pas qu'elle soit beaucoup utilisée.

Also available in: Atom PDF