Errori di connessione redis quando si utilizza il client Booksleeve Redis in Azure VM

Question

Ho recentemente iniziato a ospitare un mio progetto parallelo sulle nuove macchine virtuali di Azure. L'app utilizza Redis come cache in memoria. Tutto stava funzionando bene nel mio ambiente locale ma ora che ho spostato il codice in Azure vedo alcune strane eccezioni che escono da Booksleeve.

Quando l'app si accende per la prima volta, tutto funziona correttamente. Tuttavia, dopo circa 5-10 minuti di inattività, la prossima richiesta all'app presenta un'eccezione di rete (sono al lavoro in questo momento e non ho i messaggi di errore esatti su di me, quindi li posterò quando torno a casa se la gente pensa di essere pertinente alla discussione) Questo fa sì che il MessageQueue interno si chiuda, il che si traduce in ogni successivo Enqueue() che genera un'eccezione ("La coda è chiusa").

Quindi dopo un po 'di ricerca su google ho trovato questo post SO: Maintaining an open Redis connection using BookSleeve su un gestore di connessione DIY. Posso certamente implementare qualcosa di simile se quella è la migliore linea d'azione.

Quindi, domande:

1. è normale per il RedisConnection per chiudere periodicamente dopo un certo periodo di tempo?
2. Ho visto il metodo conn.SetKeepAlive() ma ho provato molti valori diversi e nessuno sembra fare la differenza. C'è dell'altro o sto abbaiando dall'albero sbagliato?
3. L'idea del gestore connessioni dal post è il modo migliore per gestire questo scenario?
4. Qualcuno può far luce su perché ospitare l'istanza di Redis in una nuova VM di Azure causa questo problema? Posso anche confermare che se eseguo il mio ambiente locale contro la VM di Azure Redis, ho riscontrato questo problema.

Come ho già detto, se è insolito che una connessione Redis muoia dopo l'inattività, invierò le tracce dello stack e le eccezioni dai miei registri quando torno a casa.

Grazie!

UPDATE Didier ha sottolineato nei commenti che questo può essere correlato al balanacer carico che Azure utilizza: http://blogs.msdn.com/b/avkashchauhan/archive/2011/11/12/windows-azure-load-balancer-timeout-details.aspx

Partendo dal presupposto che è il caso, quale sarebbe il modo migliore per attuare una gestione connessione che potrebbe conto di questo problema sciocco. Presumo che non dovrei creare una connessione per unità di lavoro, giusto?

Answer 1

Da altre risposte/commenti, sembra che questo sia causato dall'infrastruttura azzerata che interrompe i socket che sembrano inattivi. potrebbe semplicemente avere un timer da qualche parte che esegue periodicamente un qualche tipo di operazione, ma si noti che questo è già incorporato in Booksleeve: quando si connette controlla quale è il timeout della connessione redis e configura un heartbeat per impedire ai redis di chiudere il zoccolo. Potresti essere in grado di portarlo a termine per evitare che azzuri anche il socket.Per esempio, in una sessione di Redis-cli:

config set timeout 30 

dovrebbe configurare Redis (al volo, senza dover riavviare) per avere un secondo timeout di 30 di collegamento. Booksleeve dovrebbe quindi adottare automaticamente le misure necessarie per garantire che vi sia un battito cardiaco poco prima di 30 secondi. Notare che se questo è successo, si dovrebbe anche modificare il file di configurazione in modo che questa impostazione si applichi anche dopo il riavvio successivo.

Answer 2

Il Load Balancer in Windows Azure chiuderà la connessione dopo che X quantità di tempo dipenderà dal carico di connessione totale sul servizio di bilanciamento del carico e per questo si otterrà un timeout casuale nella connessione.

Poiché non sono ben noto alle connessioni di Redis, non sono in grado di suggerire come implementarlo correttamente, tuttavia in generale la soluzione suggerita è avere un battito cardiaco per mantenere viva la sessione. Hai la possibilità di cercare la soluzione suggerita nel blog e provare a implementare in Redis, se questo funziona per te?