2013-07-11 2 views
3

У меня возникла очень странная проблема. Я импортирую некоторые большие xml-файлы и сохраняю их в mongoDB. Алгоритм представляет собой типичный цикл асинхронный:Ошибка: подключить EADDRNOTAVAIL при обработке большой петли асинхронизации

doLoop = function(it, callback_loop) { 
    if(it < no_of_items) { 
     storeToMongo(..., function(err, result) { 
       ... 
       doLoop(it+1, callback_loop); 
     }); 
    } else { 
     callback_loop(); 
    } 
}; 
doLoop(0, function() { 
    ... 
}); 

Теперь (вдруг без каких-либо значительных изменений в коде) я получаю следующее сообщение об ошибке при выполнении цикла:

events.js:72 
     throw er; // Unhandled 'error' event 
      ^
Error: connect EADDRNOTAVAIL 
    at errnoException (net.js:901:11) 
    at connect (net.js:764:19) 
    at net.js:842:9 
    at dns.js:72:18 
    at process._tickCallback (node.js:415:13) 

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

Я попытался выяснить, что вызывает connect/net, но я потерян. В моем коде отсутствует сокет-соединение. У меня есть связь с redis, но это o.k. Это mongoDB-соединение? Но почему он внезапно заблудился?

Единственное, что помогает работать через всю петлю, чтобы выполнить вызов рекурсии в Монго обратного вызова, как это:

setTimeout(function() { 
    doLoop(it+1, callback_loop); 
},1); 

Кто там, кто имеет то, что происходит не так здесь идея?

Спасибо, heinob

+0

Вы уверены, что нет другого узла, который работает на одном сервере? попробуйте grep процесс –

+0

Да, есть еще один процесс узла. Но в прошлом они не мешали друг другу. И почему setTimeout-workaround «решает» проблему? – heinob

ответ

2

Наконец-то я нашел ответ. Это проблема в глобальном HTTP-агенте по умолчанию. См. Полное описание here.

0

Вы могли бы попробовать его с process.nextTick или setImmediate вместо setTimeout - это должно быть faster.

Как вы все делаете в одном цикле цикла событий, я предполагаю, что какой-то сетевой буфер переполняется. Возможно, узел tick перетасовывает часть вашего буфера в вашем случае.

Как вы уже упоминали, это может быть связано с простой перегрузкой «атакованной» системы.

0

Убедитесь, что вы используете проблему с записью w: 1, по крайней мере, каждую пару записей, чтобы убедиться, что вы не наводнили сокет. Скорее всего, вы делаете записи с помощью w: 0 (неподтвержденные записи) и просто в основном сбрасываете все данные в буфер сокета до тех пор, пока он не переполнится и не выключится или не исчезнет.

 Смежные вопросы

  • Нет связанных вопросов^_^