Bug #7818
problème sur l'index workflow_roles
0%
Description
Il arrive (??? sur des workflows toujours trop complexes pour en tirer quelque chose) que l'index workflow_roles ne soit plus correct, ce qui fait que limiter un listing à un statut particulier ne fonctionne pas (zéro entrées, là où le listing global affichait des demandes dans le statut donné).
(occurence du jour, https://demarches.vincennes.fr/backoffice/management/completer-un-dossier-cree-avec-un-agent-d-accueil-envoi-de-pieces-justificatives/)
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a presque 9 ans
- Fichier 0001-storage-add-lock-around-index-update-7818.patch 0001-storage-add-lock-around-index-update-7818.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Tout à fait incapable de reproduire les conditions qui pourraient amener ça, j'ai pris un peu de recul et considéré le seul truc qui restait, qu'il y ait des écritures concurrentes sur les index, ce qui peut quand même pas trop difficilement arriver avec les hashed_indexes, il me semble.
Du coup j'ai ajouté un test avec quelques forks et facilement il y a tout qui explose, d'une part la génération d'id, exécutée lors de la création de l'objet et non lors de l'écriture, ça laisse une opportunité énorme à d'autres objets pour acquérir le même id (et boum que je t'écrase). D'autre part, les index.
Pour le premier problème j'ai retiré la génération précoce de l'id (il y a dans le storage.py du code pour créer le fichier avec (os.O_CREAT | os.O_EXCL) pour éviter ça, autant l'utiliser).
Pour le second problème j'ai regardé un peu ce qu'il existait comme bibliothèque de lock et j'ai importé le code de la plus agréable.
Mis à jour par Benjamin Dauvergne il y a presque 9 ans
- Fichier 0001-use-gdbm-to-store-hashed-indexes.patch 0001-use-gdbm-to-store-hashed-indexes.patch ajouté
Il me semble qu'avec le atomic_write ça ne devrait jamais arriver qu'on lise dans le fichier d'un StorableObject pendant que quelqu'un y écrit, par contre c'est possible avec les fichiers pickle produits pour _hashed_indexes vu que ça n'utilise pas atomic_write pour sa mise à jour. À un moment on pourrait même remplacer cela par un fichier GDBM ou SQLite qui gèrent eux mêmes les locks entre lecture et écriture.
J'ai bidouillé un support gdbm qui passe ton test (mais a d'autres problèmes)... SQLite serait peut-être plus sûr.
Mis à jour par Frédéric Péters il y a presque 9 ans
Ça détourne la conversation; il y a un patch avec le lock, est-ce que ça corrige le soucis présent ? Sans doute.
Pour refaire les trucs, sans passer par postgresql, tu crées un autre ticket ?
Mis à jour par Benjamin Dauvergne il y a presque 9 ans
Le lock corrige le bug (même sans fsync il est impossible qu'un update_indexes() ne lise pas la mise à jour précédente, sauf crash disque), mais aussi à mon avis utiliser atomic_write aurait suffit en plus de la suppression d'une allocation précoce de l'id qui est le principal problème je pense.
Mis à jour par Thomas Noël il y a presque 9 ans
Ack pour 0001-storage-add-lock-around-index-update-7818.patch
Mis à jour par Frédéric Péters il y a presque 9 ans
- Statut changé de En cours à Résolu (à déployer)
commit fa801967ef22450e3802a24d35e37ce954190516
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sat Jul 11 11:44:03 2015 +0200
storage: add lock around index update (#7818)
storage: add lock around index update (#7818)