Bug #53462
champs select2 vs requêtes distribuées sur deux serveurs
0%
Description
Noté avec #41017 pour authentic, le fonctionnement de base de django-select2 n'est pas ok sur des systèmes qui n'ont pas un cache centralisé, si une requête arrive sur le serveur qui n'est pas à l'origine du jeton qu'on trouve dans l'url (le field_id), on tombe sur une 404.
Ça se simule facilement en local avec memcached, ouvrir une page, faire une recherche dans un filtre c'est ok, redémarrer memcached (ce qui le vide), refaire une recherche, 404.
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
Sur un cache non partagé on dépend du fait que haproxy maintienne les connections toujours sur le même serveur; sans ça on a rien qui fonctionne, même pas les sessions web (vu qu'on utilise cached_db par défaut dand django_debian_config.py, la bonne session se trouve sur le serveur où on l'a écrite la dernière fois).
PS: tout ça pour dire que si le problème est si fréquent avec django-select2, c'est bizarre qu'on ait pas des soucis plus grave du genre login qui foire une fois sur deux.
Mis à jour par Frédéric Péters il y a presque 2 ans
- Dupliqué par Development #60932: django_select2 et cache et multiples serveurs ajouté