Я запускаю приложение Express.js, используя Socket.io для веб-приложения чата, и случайно получаю следующую ошибку примерно 5 раз в течение 24 часов. Процесс узла заворачивается навсегда и сразу же перезапускается.
Проблема в том, что перезапуск Express выбивает моих пользователей из их комнат, и никто не хочет этого.
Веб-сервер прокси HAProxy. Нет проблем со стабильностью сокетов, только при использовании веб-сокетов и транспортов flashsockets. Я не могу воспроизвести это специально.
Это ошибка с узлом v0.10.11
:
events.js:72
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET //alternatively it s a 'write'
at errnoException (net.js:900:11)
at TCP.onread (net.js:555:19)
error: Forever detected script exited with code: 8
error: Forever restarting script for 2 time
РЕДАКТИРОВАТЬ (2013-07-22)
Добавлен как клиентский обработчик ошибок socket.io, так и обработчик необработанных исключений. Кажется, что этот ловит ошибку:
process.on('uncaughtException', function (err) {
console.error(err.stack);
console.log("Node NOT Exiting...");
});
Поэтому я подозреваю, что это не проблема Socket.io, а HTTP-запрос к другому серверу, который я делаю, или соединение MySQL / Redis. Проблема в том, что стек ошибок не помогает мне определить мою проблему с кодом. Вот вывод журнала:
Error: read ECONNRESET
at errnoException (net.js:900:11)
at TCP.onread (net.js:555:19)
Как я знаю, что вызывает это? Как я могу получить больше от ошибки?
Хорошо, не очень многословно, но вот трассировка стека с Longjohn:
Exception caught: Error ECONNRESET
{ [Error: read ECONNRESET]
code: 'ECONNRESET',
errno: 'ECONNRESET',
syscall: 'read',
__cached_trace__:
[ { receiver: [Object],
fun: [Function: errnoException],
pos: 22930 },
{ receiver: [Object], fun: [Function: onread], pos: 14545 },
{},
{ receiver: [Object],
fun: [Function: fireErrorCallbacks],
pos: 11672 },
{ receiver: [Object], fun: [Function], pos: 12329 },
{ receiver: [Object], fun: [Function: onread], pos: 14536 } ],
__previous__:
{ [Error]
id: 1061835,
location: 'fireErrorCallbacks (net.js:439)',
__location__: 'process.nextTick',
__previous__: null,
__trace_count__: 1,
__cached_trace__: [ [Object], [Object], [Object] ] } }
Здесь я использую файл политики флэш-сокета:
net = require("net")
net.createServer( (socket) =>
socket.write("<?xml version=\"1.0\"?>\n")
socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n")
socket.write("<cross-domain-policy>\n")
socket.write("<allow-access-from domain=\"*\" to-ports=\"*\"/>\n")
socket.write("</cross-domain-policy>\n")
socket.end()
).listen(843)
Может ли это быть причиной?
Ответы:
Возможно, вы уже догадались: это ошибка соединения.
«ECONNRESET» означает, что другая сторона диалога TCP внезапно закрыла свой конец соединения. Скорее всего, это связано с одной или несколькими ошибками протокола приложения. Вы можете просмотреть журналы сервера API, чтобы увидеть, если он жалуется на что-то.
Но так как вы также ищете способ проверить ошибку и, возможно, устранить ее, вы должны взглянуть на « Как отладить ошибку зависания сокета в NodeJS? », Которая была опубликована в stackoverflow по аналогичному вопросу.
РЕДАКТИРОВАТЬ (2013-07-22)
Как я уже писал выше:
Что также может иметь место: в случайное время другая сторона перегружается и в результате просто разрывает соединение. Если это так, зависит от того, к чему именно вы подключаетесь ...
Но одна вещь наверняка: у вас действительно есть ошибка чтения на вашем соединении TCP, которое вызывает исключение. Это можно увидеть, посмотрев код ошибки, который вы опубликовали в своем редактировании, что подтверждает это.
источник
Это было вызвано простым tcp-сервером, который я имел для обслуживания файла политики флэш-памяти. Теперь я могу поймать ошибку с помощью обработчика:
источник
socket.destroy()
обработчик ошибок, чтобы убедиться. К сожалению, я не могу найти документацию, требуется ли это, но это не выдает ошибку, чтобы сделать это.У меня была похожая проблема, когда приложения начинали выдавать ошибки после обновления Node. Я считаю, что это можно отследить до выпуска Node v0.9.10 этого элемента:
Предыдущие версии не допускали ошибок при сбоях со стороны клиента. Разрыв соединения с клиентом выдает ошибку ECONNRESET в узле. Я считаю, что это предназначенная функциональность для Node, поэтому исправление (по крайней мере для меня) заключалось в обработке ошибки, которую, я полагаю, вы сделали в исключениях UnCaught. Хотя я справляюсь с этим в обработчике net.socket.
Вы можете продемонстрировать это:
Сделайте простой сокет-сервер и получите Node v0.9.9 и v0.9.10.
Запустите его, используя v0.9.9, а затем попытайтесь подключиться к этому серверу по FTP. Я использую FTP и порт 21 только потому, что у меня Windows и у меня FTP-клиент, но клиент telnet не пригодится.
Затем со стороны клиента просто разорвите соединение. (Я просто делаю Ctrl-C)
Вы должны увидеть NO ERROR при использовании Node v0.9.9 и ERROR при использовании Node v.0.9.10 и выше.
В производстве я использую v.0.10. что-то и все равно выдает ошибку. Опять же, я думаю, что это предназначено, и решение состоит в том, чтобы обработать ошибку в вашем коде.
источник
Была такая же проблема сегодня. После некоторых исследований я нашел очень полезный
--abort-on-uncaught-exception
вариант Node.js . Он не только обеспечивает более подробное и полезное отслеживание стека ошибок, но также сохраняет основной файл при сбое приложения, позволяя дальнейшую отладку.источник
Я столкнулся с той же проблемой, но я смягчил ее, разместив:
перед тем
server.listen
.server
здесь HTTP-сервер Время ожидания по умолчанию составляет 2 минуты согласно документации API .источник
Другой возможный случай (но редкий) может быть, если у вас есть связь между серверами и вы установили
server.maxConnections
очень низкое значение.В ядре lib lib net.js это вызовет,
clientHandle.close()
что также приведет к ошибке ECONNRESET:источник
maxConnections
значение по умолчаниюInfinity
. Это будет иметь место только в том случае (как вы сказали), если вы явно изменили это значение.Да, ваша подача файла политики может определенно вызвать сбой.
Повторим, просто добавьте задержку в ваш код:
… И используйте
telnet
для подключения к порту. Если вы отключите telnet до того, как истечет время задержки, вы получите сбой (исключение uncaught), когда socket.write выдает ошибку.Чтобы избежать сбоя, просто добавьте обработчик ошибок перед чтением / записью сокета:
Когда вы попробуете отключение, описанное выше, вы получите сообщение журнала вместо сбоя.
И когда вы закончите, не забудьте убрать задержку.
источник
Я также получаю сообщение об ошибке ECONNRESET во время своей разработки, и я решаю ее, не используя nodemon для запуска моего сервера, просто используйте
"node server.js"
для запуска моего сервера исправленную мою проблему.Это странно, но это сработало для меня, теперь я больше никогда не вижу ошибку ECONNRESET.
источник
Я тоже имел эту ошибку и смог ее решить после нескольких дней отладки и анализа:
мое решение
Для меня VirtualBox (для Docker) был проблемой. На моей виртуальной машине настроена переадресация портов, и ошибка произошла только на перенаправленном порту.
общие выводы
Следующие наблюдения могут сэкономить вам дни работы, которые мне пришлось потратить:
-> выяснить, если что-то не так с вашей сетью (-настройки), такие как виртуальные машины, брандмауэры и т. д., это, вероятно, причина проблемы
источник
Я решил проблему, просто подключившись к другой сети . Это одна из возможных проблем.
Как обсуждалось выше, ECONNRESET означает, что диалог TCP внезапно закрыл свой конец соединения.
Возможно, ваше интернет-соединение не позволяет подключиться к некоторым серверам. В моем случае я пытался подключиться к mLab (облачной службе баз данных, в которой размещены базы данных MongoDB). И мой провайдер блокирует это.
источник
Я решил эту проблему:
npm update
в терминале, чтобы обновить npm.После этого я попробовал ту же команду npm, и хорошо, что она сработала. Я не был уверен, что это так просто.
Я использую CENTOS 7
источник
У меня была та же проблема, и кажется, что проблема была в версии Node.js.
Я установил предыдущую версию Node.js (10.14.2) и все было нормально, используя nvm (позволяет установить несколько версий Node.js и быстро переключаться с одной версии на другую).
Это не «чистое» решение, но оно может служить вам временно.
источник
Я только что понял это, по крайней мере, в моем случае использования.
Я получал
ECONNRESET
. Оказалось, что способ, которым был настроен мой клиент, действительно очень быстро ударял по серверу с помощью вызова API - и ему нужно было всего лишь один раз достичь конечной точки.Когда я это исправил, ошибка исчезла.
источник
Попробуйте добавить эти параметры в socket.io:
Я надеюсь, что это поможет вам !
источник