Produits Entr'ouvert » Passerelle

Alors, je note que ici cache = stocker une copie chaque référentiel en base. Autrement dit, on n'utilise pas le cache de Django, mais on maintient une copie des référentiels, c'est pas un "cache" mais plutôt une "synchro régulière". C'est ce qui est fait dans Referential et c'est bien.

• lorsqu'un référentiel est utilisé, renvoyer immédiatement ce qui est présent en local
• puis, si la date de dernière synchro a plus de "x" minutes, lancer un job de mise à jour (self.add_job)

Il faut donc deux choses en plus de la copie local du référentiel : sa date de dernière mise à jour, et un système de "lock" pour ne lancer qu'un seul job de mise à jour.

Pour le lock, pour ne pas lancer un job qui serait déjà en cours, je pense qu'il faut regarder ce qui est dans self.jobs_set (en ne considérant pas les jobs avec un statut failed/completed) ; ici je verrais bien un ticket spécifique pour ajouter une méthode add_job_once à côté de add_job. Ou pas :)

Reste qu'avec cette solution, si le référentiel n'est pas utilisé pendant 3 heures, alors la synchro ne se fait pas pendant 3 heures.

Pour contrer ça, on peut imaginer un cron hourly qui va lancer un job de synchro. Mais comme ça n'est que "hourly", s'il ne faut jamais que le cache ait plus d'une heure, alors on peut imaginer lancer un job asynchrone dans self.jobs, qui serait du genre :

def jobs(self):
   self.add_job_once('sync_referentials')
   super().jobs()

(self.jobs est un cron qui est lancé chaque 5 minutes, comme availability)

self.jobs est un cron qui est lancé chaque 5 minutes, comme availability

\o/ ça me plaît.

Le code de mise à jour des référentiels n'utilise pas de verrou.
(de mémoire je suis parti du connecteur BAN https://dev.entrouvert.org/issues/70982#note-15)
J'ai peut-être manqué quelque-chose (il faut me le dire si c'est flagrant) :
je procède par mise à jour des items via update_or_create
et à la fin je supprime ceux dont la date n'a pas été modifiés : .filter(..., updated__lt=last_update).delete()
De cette façon j'ai l'impression que je pourrais continuer à me passer d'un verrou, et traiter le catalogue comme les autres référentiels, sans lancer de job asynchrone :

    def daily(self):
        super().daily()
        self.update_referentials()

Le problème si tu n'as pas de verrou est le risque de lancer "n" mise à jour en même temps.

Pour un truc qui ne prend que quelques minutes, le risque est nul si tu fais juste du "cron hourly". (Sur la BAN c'est carrément du daily).

Sur le "cron jobs" qui se lance chaque 5 minutes, il faut être un peu plus sûr de toi... mais si on parle d'un truc qui prend une minute, ça doit passer.

Je ne pense pas qu'on augmente un jour la fréquence du cron jobs. Si c'est le cas, je compte sur toi pour rappeler que "ça fait pas uniquement les jobs" :) Blague à part je me dis qu'une solution plus propre, au lieu de réutiliser un cron pas prévu pour, ça serait d'ajouter un "every5min" dans nos FREQUENCY de cron, que tu serais le premier à utiliser -- ça doit se faire en quelques lignes dans commands/cron.py + passerelle/base/models.py + debian/uwsgi.ini, ça serait un premier commit facile je pense.

(si on parle d'un lancement de synchro encore plus fréquent, genre "dès que le référentiel a plus d'une minute" alors il faut vraiment locker, mais mon avis est que dans un tel besoin c'est d'abord au webservice en face d'accélérer ;) )

Automatic expiration