Hello, j'aurai bien fait une vanne sur "mais quelle hérésie une biere au pays du rouge" mais bof
Par contre que disent les logs du SGBDR ? Quelle est-elle ? Oracle ? Postgresql ? Là, genre, paradoxalement, j'aurai plutôt conservé des connexions persistantes (si elle ne le sont pas) et je me demande s'il n'y a justement pas assez de cursors ouverts pour traiter toutes les demandes, ce qui du coup, lorsqu'arrive le moment d'en traiter une, qui n'a plus "sa place" ; lâche. Mais avant de partir trop loin en conjecture, les logs seraient pratique. cordialement. Le 01/12/2014 13:27, Olivier Cortes a écrit : > Bonjour à tous, > > [merci à tous ceux qui auront la patience de lire tout mon mail. Ma > gratitude vous enveloppe châleureusement en ces humides journées > d'hiver] > > j'ai du code Django 1.6.8 où si j'active `transaction.commit()` autour > d'un simple bloc, une erreur se produit *systématiquement* quelque part > près de la BDD. > > Mais je ne sais pas *quelle erreur*, car elle n'est pas remontée. Et > bien évidement, quand elle se produit et occasionne la fermeture de la > connexion à la base, tout le process plante à cause d'un > "InterfaceError: connection already closed". > > Dans mon cas, c'est dans un worker celery avec gevent. Donc tout le > worker s'arrête, alors qu'il est censé gérer 100 tâches à la seconde, et > envoyer d'autres tâches en suivant à d'autres workers qui se retrouvent > au chomage, et forcément le gouvernement nous crée des platasses de lois > pour créer des jobs de merde, et… Ah non, c'est pas ici que je dois dire > ça. Au moins, la machine ne chauffe plus, mais autant dire que c'est pas > vraiment ce que je souhaite. > > J'ai cherché un bon moment sur Gogogle, qui m'a donné finalement ça : > > https://code.djangoproject.com/ticket/21202 > > C'était le bug parfait, presque exactement mon problème, mais Aymeric a > corrigé ce truc depuis plus d'un an, et tous mes petits pypis sont à > jour. J'ai le sentiment qu'il reste [peut-être au moins] un cas dans > lequel le problème se produit encore [à peu près pareil], puisque si je > retire le `transaction.atomic()`, je n'ai plus le "InterfaceError". De > temps j'ai un crash de type IntegrityError, justement celui que la doc > dit d'encadrer comme ça: > > try: > with transaction.atomic(): > do_some_stuff() > except IntegrityError: > handle_exception() > > Le truc c'est que quand je l'encadre pour le cas sur 10k où il se > produit, ben plus rien ne s'exécute et la connexion à la base est fermée > pour une raison inconnue (celle qui est la cause du pourquoi je vous > écris un mail de 5Ko, vous suivez ?). > > J'ai réussi à isoler un endroit où ça pète : > > https://github.com/1flow/1flow/blob/develop/oneflow/core/models/reldb/feed/rssatom.py#L581 > > Si je rajoute un "with transaction.atomic():" entre le try: et le > "new_article.add_original_data(…)", ben tout le worker s'arrête avec une > stacktrace comme http://dev.1flow.net/1flow/1flow/group/48838/ . > > Mais je suis obligé d'attendre que celery essaie de tracer le résultat > de la tâche pour qu'il se rende comte que la connexion a été fermée > avant, et du coup plus personne ne sait pourquoi ça a eu lieu. atomic() > a bouffé l'exception. > > Bref, je suis un peu dég'. Tout le bienfait de `transaction.atomic()` > part en fumée, et de temps en temps (une fois toutes les 1000 ou 10k > transactions), j'ai une tâche qui plante pour une vraie raison, et qui > forcément me plante mon worker puisque je n'ai pas d'atomic() pour me > protéger le call « comme il faut le faire que c'est écrit dans la doc, > mais RTFM, bordel™ ». > > Alors avant d'ouvrir un bug en anglais qui sera wontfix parce que je > n'arriverai pas à reproduire mon problème en 10 lignes, je serai preneur > d'une idée, une piste, un truc à essayer, un retour d'expérience, qui > pourrait me lancer sur la voie de quelque chose que j'aurais oublié. > > Si vous aimez les projets libres et que vous avez un peu de temps, ça > peut se faire autour d'une bière (ou d'un rouge, ou d'un jus de fruit, > ou d'un café) si vous êtes dans la région de bordeaux… > > PS: une fois sur 1k ou 10K ça peut paraître peu, mais sur > http://1flow.io/ c'est environ toutes les 9h… Et comme on ne peut pas > encore redémarrer les workers de l'intérieur (cf. > http://stackoverflow.com/q/14447322/654755) j'en suis réduit à > redémarrer mes workers toutes les 6h automatiquement pendant les phases > où je ne pas veiller au grain, ce qui occasionne quelques tâches qui > partent à la trappe, et ainsi de suite. Bref, pendant ce temps, sentry, > lui, est bien nourri. > > Allez a+ et merci à tous. Même si c'est pour envoyer une vanne, ça me > fera plaisir. > > -- > Olivier > > _______________________________________________ > django mailing list > [email protected] > http://lists.afpy.org/mailman/listinfo/django > -- http://www.foxmask.info _______________________________________________ django mailing list [email protected] http://lists.afpy.org/mailman/listinfo/django
