Для меня это звучит как проблема с сетью за пределами Node.js, эта ошибка «ECONNRESET» возникает, когда удаленное соединение с Node.js неожиданно закрывает сокет.

Вы используете прокси между Node и Redis?

Какая версия сервера Node / node_redis / Redis?

Я сомневаюсь, что в этом замешан агент NewRelic, но вы всегда можете попытаться воспроизвести без агента и посмотреть, решит ли это проблему. cc / @wraithan

Эти строки просто делают CLS. С большим количеством репродукций я мог бы полностью исключить агент New Relic. Но я относительно уверен, что это вызвано не нами.

Я удалил агент NewRelic, проблема все еще возникает. Прибл. каждые 3 минуты я получаю этот сбой. Ниже приведены журналы для справки.

events.js: 72
бросить эр; // Необработанное событие 'ошибка'
^
Ошибка: подключение Redis к redis1.tfs. tfs: 6379 не удалось - прочитать ECONNRESET
в RedisClient.on_error (/var/www/a/b/c/node_modules/redis/index.js:196:24)
в Socket.(/var/www/a/b/c/node_modules/redis/index.js:106:14)
в Socket.emit (events.js: 95: 17)
в net.js: 441: 14
в process._tickDomainCallback (node.js: 486: 13)
ошибка: Навсегда обнаруженный скрипт завершился с кодом: 8
ошибка: попытка перезапуска скрипта №50

Кроме того, я использую Node.JS - v0.10.35, node_redis - 0.12.1 и Redis - 2.8.4.
Я получаю доступ к Redis напрямую через IP в Node.

Я тоже столкнулся с этой проблемой, но она была решена после того, как я понял, что вчера играл со своим файлом /etc/hosts по какой-то другой причине. Не хватало:

127.0.0.1 localhost

@ ayazpasha2434 решение может быть другим для вас, но, как и другие намекают, оно определенно находится вне узла и в env / shell / OS / VM. Отойдите немного назад и смотрите на нее.

@sarathms У меня есть это отображение в моем файле hosts. Однако в моем случае машина Redis - удаленная. Просто перепроверил, у меня также есть указанное сопоставление localhost в машине Redis. По-прежнему проблема не решена.

Я тоже столкнулся с той же проблемой. Вот вывод консоли

events.js: 72
бросить эр; // Необработанное событие 'ошибка'
^
Ошибка: подключение Redis к pub-redis-10606.us-east-1-1.1.ec2.garantiadata. com: 10606 не удалось - прочтите ECONNRESET в RedisClient.on_error (C: UsersGigiDesktopeduknow_api_ver_1authnode_m
odulesredisindex.js: 196: 24)
в Socket.(C: UsersGigiDesktopeduknow_api_ver_1authnode_modulesredisindex.js: 106: 14)
в Socket.emit (events.js: 95: 17)
в net.js: 441: 14
в process._tickCallback (node.js: 442: 13)

@ ayazpasha2434 Эта строка решила мою ошибку

client.on ('ошибка', функция (ошибка) {console.error (ошибка)})

@ ayazpasha2434 У @Waterloo был для вас правильный ответ?

Похоже, возникла проблема с вашим сетевым подключением, и это не похоже на проблему с node redis. Добавление обработчика ошибок должно быть достаточным, чтобы приложение больше не зависало (и его всегда нужно прикреплять).

Я столкнулся с этой проблемой, когда отправлял http (использовать сообщение) на сервер JAVA. {[Ошибка: прочтите ECONNRESET]
код: 'ECONNRESET',
errno: 'ECONNRESET',
системный вызов: 'читать',
ответ: undefined}
Ошибка: прочтите ECONNRESET
в exports._errnoException (util.js: 856: 11)
в TCP.onread (net.js: 546: 26)
двойной обратный звонок!
POST / user_archives / create / save 500 45,306 мс - 386
Ошибка: прочтите ECONNRESET
в exports._errnoException (util.js: 856: 11)
в TCP.onread (net.js: 546: 26)

@ biggu0 Я не уверен, какое соединение это имеет с node_redis. Чтобы узнать больше о ECONNRESET, вы можете посмотреть stackoverflow .

Всем привет ,
Мы тоже наблюдаем эту проблему. Мы заметили, что это могло быть из-за redis SNAPSHOTTING. Всякий раз, когда redis делает снимок и сохраняет на диске, соединение сбрасывается. Чтобы проявить себя, я сравниваю журналы приложений с журналами отладки Redis, и время точно совпадает.

ниже приведены настройки моментального снимка в redis.conf
экономия 900 1
экономия 300 10
экономия 60 10000

Сообщите нам, если мы делаем что-то не так.

Я также часто сталкиваюсь с проблемой подключения.

ERR в RedisClient.emit (events.js: 188: 7)
Ошибка на RedisClient.on_error (/home/vcap/app/node_modules/redis/index.js:394:14)
ERR в RedisClient.(/home/vcap/app/server.js:28:13)
ERR в emitErrorNT (net.js: 1281: 8)
ERR в Socket.(/home/vcap/app/node_modules/redis/index.js:272:14)
ERR в process._tickCallback (internal / process / next_tick.js: 98: 9)
ERR Ошибка: соединение Redis с XXXXXXXX: ошибка
ERR в TCP.onread (net.js: 572: 26)
ERR в _combinedTickCallback (internal / process / next_tick.js: 74: 11)
ERR на emitOne (events.js: 96: 13)
Ошибка при экспорте ._errnoException (util.js: 1022: 11)
ERR в Socket.emit (events.js: 188: 7)

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

Привет, Ватерлоо,
Где вы поместили этот оператор client.on ('error', function (err) {console.error (err)})
и я думаю, что это заявление только для консоли вашей ошибки больше ничего.
это действительно можно использовать?
Пожалуйста, поделитесь со мной своими мыслями как можно скорее.

Заранее спасибо!!!

Здравствуйте

Я тоже столкнулся с той же проблемой

events.js: 160
бросить эр; // Необработанное событие 'ошибка'
^

Ошибка: прочтите ECONNRESET

Это решило мою проблему с:

1. Я отключил мониторинг всех своих процессов (новый реликт, эластичный apm ...)
2. Я использовал этот код
   `` Javascript
   process.on ('uncaughtException', function (err) {
   console.error (стек ошибок);
   console.log («Узел НЕ закрывается ...»);
   });

Я тоже столкнулся с этой проблемой. Я использую фреймворк sails.js с крючком, поэтому при запуске службы узла есть только одно соединение с сервером redis, мы будем использовать глобальный объект sails для доступа и работы с redis

redisClient = redis.createClient({
    host: redisConfig.host,
    port: redisConfig.port,
    db: redisConfig.db,
    retry_strategy: (retryOptions) => {
        if (retryOptions.error && retryOptions.error.code === 'ECONNREFUSED') {
            // End reconnecting on a specific error and flush all commands with
            // a individual error
            return new Error('The server refused the connection');
        }

        if (retryOptions.total_retry_time > 1000 * 60 * 60) {
            // End reconnecting after a specific timeout and flush all commands
            // with a individual error
            return new Error('Retry time exhausted');
        }

        if (retryOptions.attempt > 3) {
            // End reconnecting with built in error
            return undefined;
        }

        sails.log.debug('Handling redis retry strategy', {
            error: retryOptions.error,
            totalRetryTime: retryOptions.total_retry_time,
            attempt: retryOptions.attempt
        });

        // Reconnect after
        return Math.min(retryOptions.attempt * 100, 3000);
    }
});

Вот трассировка стека ошибки
AbortError: соединение Redis потеряно и команда прервана. Это могло быть обработано. N в RedisClient.flush_and_error (/var/sample-app/node_modules/redis/index.js:362:23)n в RedisClient.connection_gone (/ var / sample-app / node_modules / redis / index. js: 664: 14) n в RedisClient.on_error (/var/sample-app/node_modules/redis/index.js:410:10)n в Socket.(/var/sample-app/node_modules/redis/index.js:279:14)n в emitOne (events.js: 116: 13) n в Socket.emit (events.js: 211: 7) n в emitErrorNT ( internal / streams / destroy.js: 66: 8) n в /var/sample-app/node_modules/async-listener/glue.js:188:31n в args. (анонимная функция) (/ usr / lib / node_modules / pm2 /node_modules/event-loop-inspector/index.js:138:29)n в _combinedTickCallback (internal / process / next_tick.js: 139: 11) n в process._tickDomainCallback (internal / process / next_tick.js: 219: 9 ) n в process.fallback (/var/sample-app/node_modules/async-listener/index.js:563:15).

Наше приложение узла работает в контейнере Docker и будет подключаться к серверу Redis, установленному на экземпляре Linux EC2.

Мы также сталкиваемся с той же проблемой, но здесь мы разместили stunnel для проксирования redis на localhost, используя приведенную ниже конфигурацию stunnel.

fips = нет

setuid = корень

setgid = корень

pid = /var/run/stunnel.pid
отладка = 7

options = NO_SSLv2

options = NO_SSLv3
output = /var/log/stunnel.log

клиент = нет

передний план = да

[redis-cli]
клиент = да
accept = 127.0.0.1:6379
connect = redi точка отправки: 6379

узел отключается с указанными ниже ошибками каждые пару минут. Мы запускаем их через контейнеры докеров.

Подключение Redis к 127.0.0.1:6379 не удалось - прочтите ECONNRESET
в TCP.onStreamRead (внутренний / stream_base_commons.js: 111: 27)
Ошибка: подключение Redis к 127.0.0.1:6379 не удалось - прочтите ECONNRESET
в TCP.onStreamRead (внутренний / stream_base_commons.js: 111: 27)
Ошибка: подключение Redis к 127.0.0.1:6379 не удалось - прочтите ECONNRESET
в TCP.onStreamRead (внутренний / stream_base_commons.js: 111: 27)
AbortError: соединение Redis потеряно и команда прервана. Это могло быть обработано.

любое разрешение?

Мы также сталкиваемся с той же проблемой, но здесь мы разместили stunnel для проксирования redis на localhost, используя приведенную ниже конфигурацию stunnel.

fips = нет

setuid = корень

setgid = корень

pid = /var/run/stunnel.pid
отладка = 7

options = NO_SSLv2

options = NO_SSLv3
output = /var/log/stunnel.log

клиент = нет

передний план = да

[redis-cli]
клиент = да
accept = 127.0.0.1:6379
connect = redi точка отправки: 6379

узел отключается с указанными ниже ошибками каждые пару минут. Мы запускаем их через контейнеры докеров.

Подключение Redis к 127.0.0.1:6379 не удалось - прочтите ECONNRESET
в TCP.onStreamRead (внутренний / stream_base_commons.js: 111: 27)
Ошибка: подключение Redis к 127.0.0.1:6379 не удалось - прочтите ECONNRESET
в TCP.onStreamRead (внутренний / stream_base_commons.js: 111: 27)
Ошибка: подключение Redis к 127.0.0.1:6379 не удалось - прочтите ECONNRESET
в TCP.onStreamRead (внутренний / stream_base_commons.js: 111: 27)
AbortError: соединение Redis потеряно и команда прервана. Это могло быть обработано.

любое разрешение?

То же самое для меня, я думаю, что это проблема с stunnel

Я также столкнулся с такой же ошибкой

{ Error: Redis connection to xx.xx.x.x:6379 failed - read ECONNRESET" 

at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' 

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

@Ayaz Не могли бы вы открыть эту проблему, потому что эта проблема не решена полностью, люди только обработали ответ об ошибке, но проблема все еще не решена.

Bumping: та же проблема здесь:

error: Error: Redis connection to xx.yy.zz.aa:6379 failed - read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:205:27) { errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' },

Я вижу то же самое с:

• NodeJS v12.16.3
• Фреймворк NestJS
• IOredis: 4.2
• nestjs-redis: 1.2.8

Redis предоставляется с помощью Google Cloud MemoryStore.

Журналы показывают:

[ioredis] Необработанное событие ошибки: ошибка: прочтите ECONNRESET

Это происходит примерно один раз каждые 24 часа без какой-либо конкретной причины или тех же шагов, это просто происходит

@ robertop87
Я вижу ту же проблему. Redis предоставляется с помощью Google Cloud MemoryStore. Вы решили эту проблему?

Также наблюдается очень похожая проблема с Cloud run / Cloud Functions при подключении к Cloud Memory Store. Это могло произойти, когда базовые ресурсы были случайно остановлены Google слишком рано.

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

IORedis по умолчанию использует стратегию повторного подключения при ошибке, но по какой-то причине этого не происходит.

Что я сделал, так это добавил в конфигурацию следующее:

reconnectOnError: (error): boolean => {
  console.log('Always reconnect on error', error)
  return true
}

Ошибка ECONNRESET все еще присутствует, но теперь мое соединение повторяется, и мой экземпляр Google больше не зависает.

CC: @ hkd987

Подробнее о reconnectOnError читайте здесь:

@ robertop87 Произведено новое развертывание с определенной конфигурацией, чтобы всегда reconnectOnError возвращал true. Это похоже на проблему, которую необходимо повторно открыть или создать новую заявку, поскольку это происходит в последней версии.