You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Devons-nous mettre en place une procédure de sauvegarde périodique du contenu de la base Redis si jamais le serveur sur lequel est installé l'extracteur venait à s'arrêter brutalement ? Est-ce que tu sais si Celery intègre une procédure de reprise des tâches qui n'ont pas été réalisées jusqu'au bout ?
The text was updated successfully, but these errors were encountered:
Réponse d'@rouault :
Oui la sauvegarde de la base pourrait éventuellement être pertinente (quoique ça voudrait dire que le serveur est submergé de requêtes en attente, donc problème quelque part de dimensionnement).
J'ai fait le test suivant:
démarrer le frontend et le service redis uniquement
soumettre un job
faire un restart du service redis
lancer le backend
Et le job soumis est bien exécuté.
Par contre un job qui serait en cours d'exécution au moment du plantage du serveur restera indéfiniment dans un état STARTED / PROGRESS et ne sera pas redémarré au redémarrage du backend. Si on lance un PUT {"status": "STOP_REQUESTED"} il changera vers cet état, mais comme il n'est pas en exécution par le backend, il restera dans cet état.
Devons-nous mettre en place une procédure de sauvegarde périodique du contenu de la base Redis si jamais le serveur sur lequel est installé l'extracteur venait à s'arrêter brutalement ? Est-ce que tu sais si Celery intègre une procédure de reprise des tâches qui n'ont pas été réalisées jusqu'au bout ?
The text was updated successfully, but these errors were encountered: