Projet

Général

Profil

Bug #18351

connexion postgresql fermée lors d'exports CSV/ods/xls

Ajouté par Frédéric Péters il y a plus de 6 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
01 septembre 2017
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Cf #18329 pour une occurence.

Exception:
  type = '<class 'psycopg2.InterfaceError'>', value = 'connection already closed'

Stack trace (most recent call first):
  File "/usr/lib/python2.7/dist-packages/wcs/sql.py", line 340, in f
   338             return func(*args, **kwargs)
   339         except psycopg2.Error:
>  340             get_connection().rollback()
   341             raise
   342     return f
...
  File "/usr/lib/python2.7/dist-packages/wcs/qommon/http_response.py", line 163, in process_after_jobs
   161                 job_function(job=job)
   162             except:
>  163                 get_publisher().notify_of_exception(sys.exc_info())
   164                 job.exception = traceback.format_exc()
   165                 job.status = N_('failed')

En première analyse j'imagine embrouille entre la connexion postgresql du cycle requête/réponse et le thread créé pour exécuter les afterjobs. (En local en runserver je n'ai pas reproduit, il y a peut-être en plus un truc en rapport avec uwsgi).


Fichiers

Révisions associées

Révision 25e6b3e7 (diff)
Ajouté par Frédéric Péters il y a plus de 6 ans

misc: create a new publisher object for running afterjobs (#18351)

Historique

#1

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

En première analyse j'imagine embrouille entre la connexion postgresql du cycle requête/réponse et le thread créé pour exécuter les afterjobs. (En local en runserver je n'ai pas reproduit, il y a peut-être en plus un truc en rapport avec uwsgi).

Au final non, ce n'est pas lié aux threads, c'est qu'une autre requête peut être prise en charge par le même processus uwsgi et il y aura réutilisation de l'objet publisher, création puis terminaison d'une connexion à postgresql. Et comme le même publisher était encore en cours d'exécution dans le thread de l'afterjob, boom.

Correction simple en passant une copie du publisher pour l'exécution de l'afterjob. (un deepcopy n'est pas possible à cause de WSGIRequest). Également testé sur la recette.

#2

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

Ack (c'est un peu lié aux threads quand même :) ).

#3

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

  • Statut changé de En cours à Résolu (à déployer)
commit 25e6b3e7e5f15e725af1b769fe0b929cbf2dbc6d
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Fri Sep 1 12:39:30 2017 +0200

    misc: create a new publisher object for running afterjobs (#18351)
#4

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

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF