Development #48407
Mis à jour par Frédéric Péters il y a plus de 3 ans
(mon option pour résoudre #46674, où un afterjob prend du temps et se trouve tué par uwsgi)
Pour certains jobs, je pense aux actions en masse ou à l'import de fiches depuis un csv (mais ça peut être plus fin, genre l'import de fiches depuis un csv uniquement s'il y a plus de n lignes dans le CSV), il faudrait qu'ils ne soient pas exécutés en thread démarré depuis d'uwsgi mais plutôt avoir le traitement requête/réponse d'uwsgi, mais via une mécanique avancée de uwsgi (spooler, queue, etc.) ou peut-être simplement(?) cron. cron passer dessus, hors du cycle requête/réponse.
Ça demande dans tous les cas que tout l'état nécessaire soit enregistré dans le job. (alors que là on profite de locals()).
Aussi il faut quand même dans l'idée cron, il faudra malgré tout le code lancé par cron quelque chose qui puisse assurer l'exécution de plusieurs afterjobs en parallèle, que ça soit via async/await, multiprocessing ou autre. (histoire que quelqu'un qui lance une action de masse ne bloque pas toute la plateforme).
Pour certains jobs, je pense aux actions en masse ou à l'import de fiches depuis un csv (mais ça peut être plus fin, genre l'import de fiches depuis un csv uniquement s'il y a plus de n lignes dans le CSV), il faudrait qu'ils ne soient pas exécutés en thread démarré depuis d'uwsgi mais plutôt avoir le traitement requête/réponse d'uwsgi, mais via une mécanique avancée de uwsgi (spooler, queue, etc.) ou peut-être simplement(?) cron. cron passer dessus, hors du cycle requête/réponse.
Ça demande dans tous les cas que tout l'état nécessaire soit enregistré dans le job. (alors que là on profite de locals()).
Aussi il faut quand même dans l'idée cron, il faudra malgré tout le code lancé par cron quelque chose qui puisse assurer l'exécution de plusieurs afterjobs en parallèle, que ça soit via async/await, multiprocessing ou autre. (histoire que quelqu'un qui lance une action de masse ne bloque pas toute la plateforme).