Produits Entr'ouvert » Zoo

Le select_for_update() va attendre que «l'autre» requête se soit terminée, est-ce ce que l'on veut ? Avec un nowait=True on pourrait obtenir l'info qu'un lock est en place par ailleurs et renvoyer un message d'erreur (via un try: select_for_update(nowait=True) except: erreur) ... Je ne sais pas ce qui est le mieux, à vrai dire.

J'arrivais mieux à penser la chose avec un simple lock bloquant mais oui c'est plus efficace de ne pas bloquer.

MMmhh t'as pas géré pour les select_for_update, là (y'en a deux sans noawait, et un sans try/except)

• à l'exécution du flux (pour éviter une écriture concurrente dans 'cles_de_federation')
• à la création du flux (pour être sûr qu'on prend la bonne décision concernant le choix entre créer une fédération ou utiliser l'existante)

Je me dis qu'à la création on veut toujours bloquer parce que jusqu'à présent on a aucune erreur attendue à la génération d'un flux et là on en créerait une, non seulement ça a échoué mais on a généré aucun flux; j'aime pas inventer des situations inconnues.

À l'exécution effectivement on peut simplement abandonner.

Dans mon dernier patch j'ai viré les lock au niveau de def synchronize() et CalculerQF.create() (d'ailleurs je pourrai factoriser encore un peu plus maintenant que j'ai mon flag FragmentBuilder.lock_individus et mettre ça dans FragmentBuilder.create().

Et oui bloquer à la création qui est aussi le moment d'exécution de 99% des flux, c'est bloquer tout le temps (sachant qu'on a un timeout de 20s sur les appels RSU, bien trop long finalement sachant qu'on peut synchroniser jusqu'à 3 applications), on a des blocages en synchro jusqu'à 30s. De toute façon si technocarte timeout on aura tous les workers bloqués assez vite (5 personnes lance une synchro techno, personne utilise zoo pendant 20s). Idéalement on devrait beaucoup baisser les timeout et tant pis si ça passe pas (je le leur dirai), on peut aussi monter le nombre de workers et/ou utiliser massivement le mode thread/greenlet d'uwsgi parce que finalement zoo c'est que des I/O (peut-être plus greenlet parce que psycopg2 et threads ça m'inquiète toujours un peu, même si logiquement on a pas de connections partagées entre threads).

Je suis pour poser ce patch ainsi sans toucher aux timeouts pour l'instant, sujet encore trop sensible face à une réalité qu'on ne connait pas (on n'a jamais vu ce que tout cela donne en prod, "quand les applications sont chargées", etc). Comme toi, pas envie de trouver des solutions à des problèmes inconnues.