Ich habe kürzlich begonnen, ein Nebenprojekt von mir auf den neuen Azure-VMs zu hosten. Die App verwendet Redis als speicherinternen Cache. In meiner lokalen Umgebung hat alles reibungslos funktioniert, aber jetzt, da ich den Code in Azure verschoben habe, werden einige seltsame Ausnahmen von Booksleeve angezeigt.

Wenn die App zum ersten Mal gestartet wird, funktioniert alles einwandfrei. Nach ca. 5-10 Minuten Inaktivität tritt bei der nächsten Anforderung an die App eine Netzwerkausnahme auf (ich bin gerade auf der Arbeit und habe nicht die genauen Fehlermeldungen, daher werde ich sie veröffentlichen, wenn ich nach Hause komme, wenn Leute denken, dass sie für die Diskussion wichtig sind) Dies bewirkt, dass die interne MessageQueue geschlossen wird, was dazu führt, dass jede nachfolgende Enqueue () eine Ausnahme auslöst ("The Queue Is Closed").

Nach einigem googeln habe ich diesen SO Post gefunden:Aufrechterhaltung einer offenen Redis-Verbindung mit BookSleeve über einen DIY Verbindungsmanager. Ich kann sicherlich etwas Ähnliches implementieren, wenn das die beste Vorgehensweise ist.

Also, Fragen:

Ist es normal, dass die RedisConnection nach einer bestimmten Zeit regelmäßig geschlossen wird?Ich habe das gesehenconn.SetKeepAlive() Methode, aber ich habe viele verschiedene Werte ausprobiert und keiner scheint einen Unterschied zu machen. Gibt es noch mehr oder belle ich den falschen Baum an?Ist die Idee des Verbindungsmanagers aus dem obigen Beitrag der beste Weg, um mit diesem Szenario umzugehen?Kann jemand zusätzliche Aufschluss darüber geben, warum das Hosten meiner Redis-Instanz in einer neuen Azure-VM dieses Problem verursacht? Ich kann auch bestätigen, dass dieses Problem auftritt, wenn ich meine lokale Umgebung mit der Azure Redis-VM ausführe.

Wie gesagt, wenn es ungewöhnlich ist, dass eine Redis-Verbindung nach Inaktivität abbricht, werde ich die Stack-Traces und Ausnahmen aus meinen Protokollen veröffentlichen, wenn ich nach Hause komme.

Vielen Dank!

AKTUALISIEREN Didier wies in den Kommentaren darauf hin, dass dies möglicherweise mit dem von Azure verwendeten Lastenausgleich zusammenhängt:http://blogs.msdn.com/b/avkashchauhan/archive/2011/11/12/windows-azure-load-balancer-timeout-details.aspx

Angenommen, dies ist der Fall, was wäre der beste Weg, um einen Verbindungsmanager zu implementieren, der dieses doofe Problem erklären könnte. Ich gehe davon aus, dass ich keine Verbindung pro Arbeitseinheit herstellen sollte, oder?