DatabaseLockError: Unable to get write lock on /home/sith/Sith/./sith/search_indexes/xapian: already locked

[ae-utbm-sentry[bot]]

Sentry Issue: SITH3-2B

DatabaseLockError: Unable to get write lock on /home/sith/Sith/./sith/search_indexes/xapian: already locked
(14 additional frame(s) were not displayed)
...
  File "haystack/signals.py", line 49, in handle_save
    index.update_object(instance, using=using)
  File "haystack/indexes.py", line 324, in update_object
    backend.update(self, [instance])
  File "xapian_backend.py", line 274, in update
    database = self._database(writable=True)
  File "xapian_backend.py", line 1141, in _database
    database = xapian.WritableDatabase(self.path, xapian.DB_CREATE_OR_OPEN)
  File "__init__.py", line 9374, in __init__
    _xapian.WritableDatabase_swiginit(self, _xapian.new_WritableDatabase(*args))

[klmp200]

Sans regarder trop en détail, ça doit être un problème d'accès concurrent au fichier d'index xapian Ça doit arriver quand 2 users ou plus sont crées exactement en même temps je dirais, pareil pour les posts forumç @Hyask une idée de comment rendre ça plus fiable sans avoir besoin de spawn un autre service ?

Une technique pourait être de mettre ça dans une file d'attente quand ça arrive et de faire passer un cron mais ça veut dire plus de complexité au niveau de l'infra et c'est pas ouf pour les nouveaux

Sinon une autre technique c'est de retry sur l'erreur, le downside pourrait être d'avoir des timeout de temps en temps

Quoi qu'il arrive, il faut pouvoir recover proprement de l'erreur

Rappel, il y a plusieurs process en même temps du sith qui tournent, c'est uwsgi qui fait ça. Le seul état partagé étant évidement la BDD

[TheoDurr]

J'ai lu que c'était aussi par manque de mémoire de la machine.

https://trac.xapian.org/ticket/624.

L'hyperviseur indique une surcharge de la mémoire tandis que la vm indique 5% d'utilisation de la mémoire.

[Hyask]

Alors, deux choses:

• retry l'erreur une fois ou deux, c'est une possibilité, mais faut pas retry à l'infini ou juste trop de fois, sinon comme tu dis, on va avoir des timeout.
• c'est à vérifier, mais il me semble que l'indexer est lancé aussi automatiquement régulièrement par un cron, donc si c'est bien toujours le cas, l'erreur peut juste être ignorée, parce que l'objet se fera indexer plus tard de toutes façons

Pour le coup du manque de mémoire, ça a pas l'air d'être ça: là on a bien already locked, pas could not fork

[TheoDurr]

On a pas retry l'erreur, mais on peut pas l'ignorer étant donné que ça génère une erreur côté serveur

[Hyask]

Oui, je parle bien de la manière dont on peut corriger l'erreur dans le code côté serveur, je pense que c'est ce que @klmp200 voulait dire aussi. Donc dans le code: soit tu retry une fois ou deux, soit tu ignores si on est bien dans la situation ou l'indexer tourne quoi qu'il arrive régulièrement, mais c'est à vérifier.