Project

General

Profile

Bug #53462

champs select2 vs requêtes distribuées sur deux serveurs

Added by Frédéric Péters about 2 months ago. Updated about 2 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
27 Apr 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

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.

History

#1

Updated by Benjamin Dauvergne about 2 months ago

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.

Also available in: Atom PDF