Каналы Django: НЕИЗВЕСТНАЯ ошибка при записи в сокет. Соединение потеряно
У нас есть каналы Django в сочетании с экземпляром uvicorn и Azure Redis. Наш часовой завален такими ошибками, как:
Exception in ASGI application
ssd.consumers in disconnect
Error UNKNOWN while writing to socket. Connection lost.
Исключение создается в файле asyncio/streams.py, как показано в примере.
Моя главная проблема заключается в том, что я понятия не имею, прерывает ли Redis это соединение или сервер не хочет его сохранять? Любые подсказки приветствуются. Я не наблюдал такого поведения на локальном экземпляре Redis. Мы работаем со следующими пакетами:
Django = "~4.2"
redis = "^4.3.1"
channels = {extras = ["daphne"], version = "^4.0.0"}
channels-redis = "^4.1.0"
uvicorn = {extras = ["standard"], version = "^0.24.0.post1"}
Стоит отметить, что в большинстве случаев это работает, веб-сокеты работают, иногда просто случайно выдается упомянутое выше исключение.
Ответы 2
redis использует пакет asyncio для установки соединения через веб-сокет и асинхронного конвейера данных между клиентом и сервером. Сервер использует различные функции пакета asyncio для связи с клиентом, и большинство из них работают нормально. Однако, если вы проверите PyPi на наличие channels-redis, вы увидите, что эта библиотека не проходит тесты и нестабильна.
Тем не менее, вы должны быть в состоянии заставить его работать стабильно. Убедитесь, что вы используете Python 3.8+, как это требуется для redis, как показано на странице PyPi. Как я объяснил, channels-redis может быть в некотором отношении нестабильным, но я думаю, что в основном он нестабильен при поиске правильной серии пакетов, которые полностью совместимы и вызывают правильные имена функций, поскольку они меняются в библиотеках. Я рекомендую использовать что-то новое, но не слишком старое, с хорошей поддержкой библиотек. Сейчас я предлагаю Python 3.11.8.
Когда вы устанавливаете/обновляете пакеты с помощью pip, вы должны устанавливать их в том порядке, в котором этого требуют зависимости, и они должны устанавливать версию пакета, совместимую с другими пакетами. Здесь вы можете проверить стабильность каждой версии и выполнить откат channels-redis, чтобы увидеть, изменилось ли что-нибудь, сверившись redis с версией и датой выпуска на PyPi.
Когда вы устанавливаете последнюю версию Django для Python 3.11.8, вам следует установить redis и channels-redis, и, скорее всего, все будет работать. Но, возможно, стоит принять во внимание текущие версии вашего пакета или вообще использовать тестовый сервер, если вы работаете в рабочей среде.
pip install Django --upgrade
pip install redis --upgrade
pip install channels-redis --upgrade
Что ж, похоже, проблема в кеше Azure для Redis: после того, как я развернул Redis в кластере и установил соединение, он перестал выдавать исключения. Поскольку мне приходится использовать кэш Azure для Redis, я буду отлаживать его дальше. Redis я развернул: artehub.io/packages/helm/bitnami/redis
По-видимому, в channels_redis lib можно указать дополнительные настройки, которые явно не указаны в документации. Поскольку Azure Cache For Redis не является либеральным, он отключал время простоя соединений. Изменение моей настройки на эту решенную проблему:
CHANNEL_LAYERS = {
"default": {
"BACKEND": "channels_redis.core.RedisChannelLayer",
"CONFIG": {
"hosts": [
{ # specifying host as dict with additional keys for redis-py client was a key to solve it.
"address": CHANNELS_REDIS_URL,
"retry_on_timeout": True,
"health_check_interval": 1,
"socket_keepalive": True,
}
],
"capacity": 1500,
"expiry": 5,
},
},
}
Привет! Я вернулся с отзывами, поэтому я попробовал каждую версию
channels-redisиredisв различных конфигурациях, ни одна из них не помогла. В настоящее время я исправил версии ``` redis = "^5.0.0" Channels-redis = "^4.2.0" Channels = { extras = ["daphne"], version = "^4.0.0" } Django = "~ 4.2" ``` и продолжаю отлаживать экземпляр Redis, отличный от экземпляра, арендованного у Azure.