Ошибки подключения Redis при использовании клиента Redis Booksleeve в виртуальной машине Azure

Недавно я начал размещать сторонний проект на новых виртуальных машинах Azure. Приложение использует Redis в качестве кеша в памяти. В моей локальной среде все работало нормально, но теперь, когда я переместил код в Azure, я вижу странные исключения, возникающие в Книжном рукаве.

Когда приложение запускается, все работает нормально. Однако примерно через 5-10 минут бездействия следующий запрос к приложению вызывает сетевое исключение (я сейчас на работе и у меня нет точных сообщений об ошибках, поэтому я буду публиковать их, когда вернусь домой, если люди думают, что они «уместны для обсуждения». Это приводит к закрытию внутреннего MessageQueue, что приводит к тому, что каждый последующий Enqueue () вызывает исключение («Очередь закрыта»).

Так что после некоторого поиска в Google я нашел этот пост:Поддержание открытого соединения Redis с помощью BookSleeve о менеджере соединений DIY. Я, конечно, могу реализовать нечто подобное, если это лучший способ действий.

Итак, вопросы:

Is it normal for the RedisConnection to close periodically after a certain amount of time? I've seen the conn.SetKeepAlive() method but I've tried many different values and none seem to make a difference. Is there more to this or am I barking up the wrong tree? Is the connection manager idea from the post above the best way to handle this scenario? Can anyone shed any additional light on why hosting my Redis instance in a new Azure VM causes this issue? I can also confirm that if I run my local environement against the Azure Redis VM I experience this issue.

Как я уже сказал, если соединение Redis будет необычным для соединения после бездействия, я опубликую трассировку стека и исключения из моих журналов, когда вернусь домой.

Спасибо!

UPDATE В комментариях Дидье указал, что это может быть связано с балансировщиком нагрузки, который использует Azure:http://blogs.msdn.com/b/avkashchauhan/archive/2011/11/12/windows-azure-load-balancer-timeout-details.aspx

Предполагая, что это так, что было бы лучшим способом реализовать диспетчер соединений, который мог бы объяснить эту глупую проблему. Я предполагаю, что не должен создавать соединение на единицу работы, верно?

Ответы на вопрос(2)

Ваш ответ на вопрос