Produits Entr'ouvert » Hobo

Donc le souci à la base c'est la sérialisation des arguments lorsqu'on provisionne les messages HTTP depuis le spooler, ne peut pas dépasser 64k¹, et sur un provisionning full des rôles ou des usagers, ça dépassera souvent.

¹ https://uwsgi-docs.readthedocs.io/en/latest/Spooler.html#spool-files

Bien vu.

Ce serait plutôt provision_spooler.spool(**kwargs) si on veut rester sur ton idée.

Mais je trouve que ça complique la lecture d'introduire une nouvelle méthode provision_spooler, pourquoi ne pas faire body = pickle.dumps(data) dans le middleware, passer ça à spooler.py::provision où tu peux faire un data = pickle.loads(kwargs['body']) et voilà ?

Emmanuel Cazenave a écrit :

Ce serait plutôt provision_spooler.spool(**kwargs) si on veut rester sur ton idée.

Non, ce n'est plus la bonne API depuis des années¹.

Mais je trouve que ça complique la lecture d'introduire une nouvelle méthode provision_spooler, pourquoi ne pas faire body = pickle.dumps(data) dans le middleware, passer ça à spooler.py::provision où tu peux faire un data = pickle.loads(kwargs['body']) et voilà ?

Je trouve que ça complique le middleware d'y voir des détails d'implémentation de uwsgi.

¹ https://github.com/unbit/uwsgi/commit/164069e1948c4d30552606dd572c21b90d61a65f

Benjamin Dauvergne a écrit :

Je trouve que ça complique le middleware d'y voir des détails d'implémentation de uwsgi.

On est déjà dans un if 'uwsgi' in sys.modules ...

A part ça ton patch ne marche pas :

[spooler /var/lib/passerelle/spooler pid: 33441] managing request uwsgi_spoolfile_on_cazino-laptop_33466_1_68655914_1631792990_225889 ...
Traceback (most recent call last):
  File "/home/cazino/envs/publik-env-py3/lib/python3.9/site-packages/uwsgidecorators.py", line 60, in manage_spool_request
    vars = _decode_from_spooler(vars)
  File "/home/cazino/envs/publik-env-py3/lib/python3.9/site-packages/uwsgidecorators.py", line 41, in _decode_from_spooler
    return dict((_decode1(K), _decode1(V)) for (K, V) in list(vars.items()))
  File "/home/cazino/envs/publik-env-py3/lib/python3.9/site-packages/uwsgidecorators.py", line 41, in <genexpr>
    return dict((_decode1(K), _decode1(V)) for (K, V) in list(vars.items()))
  File "/home/cazino/envs/publik-env-py3/lib/python3.9/site-packages/uwsgidecorators.py", line 31, in _decode1
    return val.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

Emmanuel Cazenave a écrit :

A part ça ton patch ne marche pas :
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

(pour info ça correspond à un ticket catégorie bug côté uwsgi https://github.com/unbit/django-uwsgi/issues/10, j'étais déjà tombé dessus)

Valentin Deniaud a écrit :

Emmanuel Cazenave a écrit :

A part ça ton patch ne marche pas :
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

(pour info ça correspond à un ticket catégorie bug côté uwsgi https://github.com/unbit/django-uwsgi/issues/10, j'étais déjà tombé dessus)

C'est fou ça, en gros on a déjà de la chance que ça fonctionne dans le cas général, parce que kwargs c'est bien un pickle aussi.

Pour la lisibilité, plutôt utiliser force_bytes que les .encode('utf-8') ? (si tant est que ça fait bien la même chose, moi et l'encodage sommes fachés)

Emmanuel Cazenave a écrit :

uwsgidecorators c'est vraiment limpide.

Je vais proposer qu'on s'en passe carrément parce que c'est du caca.

Thomas Noël a écrit :

Je vais proposer qu'on s'en passe carrément parce que c'est du caca.

Oui désolé de mon intervention intempestive sur ce ticket, c'est juste pour dire que j'ai envie de proposer un remplacement à uwsgidecorators dans un autre ticket (genre un module hobo.utils.uwsgi); c'était juste pour voir si il y avait un assentiment général sur le sujet ou si tout le monde s'en fout.

Benjamin Dauvergne a écrit :

Thomas Noël a écrit :

Je vais proposer qu'on s'en passe carrément parce que c'est du caca.

Oui désolé de mon intervention intempestive sur ce ticket, c'est juste pour dire que j'ai envie de proposer un remplacement à uwsgidecorators dans un autre ticket (genre un module hobo.utils.uwsgi); c'était juste pour voir si il y avait un assentiment général sur le sujet ou si tout le monde s'en fout.

Pas trop d'avis sur le sujet, mais c'est vrai que uwsgidecorators est assez loufoque. Ceci dit, si "ça marche"...

Thomas Noël a écrit :

Pas trop d'avis sur le sujet, mais c'est vrai que uwsgidecorators est assez loufoque. Ceci dit, si "ça marche"...

Ben ça me fait un peu peur sur tous les autres projets où s'en sert sans voir que ça va planter un jour, on utilise pickle via pass_argument=True partout.

Si une bonne âme veut bien tagger/déployer demain ...

Et si ça merde encore ça me de reverter pour revenir à l'état provisionning HTTP synchrone.

Benjamin Dauvergne a écrit :

Je vais proposer qu'on s'en passe carrément parce que c'est du caca.

Je suis d'accord que ça inspire pas du tout confiance, mais probablement pas besoin de le virer complètement, s'en servir comme le fait wcs de façon très minimaliste, en passant juste un nom de tenant et un identifiant de job, avec un objet job qui peut se sérialiser/désérialiser complètement en dehors du magma de uwsgidecorators.

Emmanuel Cazenave a écrit :

ça me de reverter

ça me va de reverter