lavoratori multipli con gevent-socketio non riesce con il trasporto XHR-polling a causa di sessioni

Question

Attualmente sto cercando di scalare gevent-socketio tra più lavoratori con il server gunicorn utilizzando il lavoratore socketio.sgunicorn.GeventSocketIOWorker. Sto usando websocket quando esiste altrimenti sto forzando il polling XHR (per IE ecc.).

Il polling XHR richiede una sessione per tenere traccia dei seguenti sondaggi ma non appena passo da uno a due o più lavoratori le richieste iniziano a espandersi tra loro, il che significa che lo stato viene perso e tutto si interrompe.

penso che le seguenti righe di codice è rilevante: https://github.com/abourget/gevent-socketio/blob/master/socketio/handler.py#L104-106 suppongo ho bisogno di qualche altro motore di memorizzazione, ad esempio redis che sto usando per regolari PubSub-azioni, ma questo è profondo all'interno della libreria vera e propria.

Quindi la mia domanda è: come faccio ad andare dalla memorizzazione delle sessioni in memoria di un altro motore di back-end a livello globale nella mia applicazione (lo fa a ignorare con grazia il codice di sessione nel link qui sopra?) , senza dover modificare la libreria stessa? Something like PHP's session directives in php.ini. Suppongo che si possa sostenere che questa è una domanda Python molto generica, ma ho problemi a trovare informazioni rilevanti, e sono anche sicuro che funzionerà con questa libreria.

Oppure, in alternativa, come utilizzare il trasporto xhr-polling di gevent-socketio su diversi server e dipendenti (senza appiccicosità)?

Grazie!

Answer 1

Questa è ovviamente una limitazione di socketio. Da quello che vedo sul Web, la gestione delle sessioni viene in genere eseguita a livello di framework Web piuttosto che a server Web uno. socketio prova a farlo da solo, a livello inferiore, e lo fa in modo limitato. Immagino che gli autori pensassero che una soluzione a tutti gli effetti sarebbe un eccesso. Nel tuo caso, hanno dimostrato di essere sbagliati.

Esistono solo due modi per superare le limitazioni che richiedono modifiche logiche: applicazione di patch all'origine e patching nel runtime. Scegli quello che ti piace di più (o, beh, disgusta il minimo: ^)). Per la seconda opzione, suggerisco di sostituire request_tokens e/o il codice che lo crea con un'altra entità con la stessa interfaccia. A causa dei motivi indicati nel primo paragrafo, penso davvero che gli autori di socket possano accettare una patch di origine che consenta di utilizzare meccanismi di gestione delle sessioni esterne se ne proponi uno.

I percorsi standard per le informazioni sulla sessione sono: memoria condivisa, file, database. Ti suggerisco di cambiare la logica in modo tale che socketio usi lo stesso meccanismo del tuo framework web (o di qualsiasi altra cosa componga le tue pagine).

Answer 2

Guardate gli esempi qui:

https://github.com/abourget/gevent-socketio/tree/master/examples/pyramid_backbone_redis_chat_persistence

Essa mostra come usare Redis come una coda di messaggi distribuito

Answer 3

Solo un pensiero, come io sto avendo lo stesso problema; invece di lasciare la forchetta di Gunicorn (con la flag -w), forse potresti generare più processi di gunicorn su porte diverse, quindi usare nginx per bilanciarli usando uno "upstream" block with "sticky" session. Credo che sia così che l'implementazione nodejs gestisce il multiprocesso dei lavoratori quando non condivide gli stati con Redis.