Тимур Шемсединов

forever, pm2, impress, но нельзя злоупотреблять этим, нужно стараться так писать, чтобы сбои не были нормальным режимом и процессы жили месяцами.

Я рекомендую все же TCP, потому, что на стандартном IPC решение не будет масштабируемым, его нельзя будет размазать на несколько серверов. А если у Вас не стоит задача подключать много клиентов, например, будет 10-50к подключений, то это и один процесс может обработать, тут даже кластера из мастера/воркера не нужно, это очень маленькие цифры. Один сервер может потянуть до 2-3млн соединений даже (в зависимости от интенсивности обмена, конечно). Я не понял фразу "клиенты теряются и это очевидно", не понятно, куда теряются и это не очевидно. И еще вот примеры мои дам, которые я студентам на лабы даю по IPC и TCP: https://github.com/HowProgrammingWorks/InterProces...

Ничего в памяти не зависнет, file.destroy() на this.on("close"... не нужно вызывать ни в случае успеха, ни в случае ошибки, после вызова pipe все случится автоматически.

У меня подобная штука, что я заметил: при публикации новых версий это повторяться, а если 1-2 дня не публикуете, то скачиваний умеренное количество. Думаю, что люди, использующие пакеты применяют автоматическое тестирование и при публикации новых версий зависимостей, запускают тестирование по новой. У меня таким образом иногда до 2-3тыс загрузок бывает в сутки.

Не использовать nconf и прочую чухню. А загружать JSON файлы через var config = requere('config.js'); или через fs и потом JSON.parse()

Теперь подключение модулей несколько изменилось, для этого случая в /applications/my-app/config/sandbox.js в раздел api добавьте 'node-expat' и тереь из любого обработчика можно будет обращаться к нему как api.nodeExpat. Не забудьте обновить версию Impress до сегодняшней 0.1.372, там исправлена проблема с заменой тире в именах модулей, т.е. преобразованием spinalToCamel, например: node-expat в nodeExpat, потому, что писать api['node-expat'] как-то не красиво, лучше api.nodeExpat и я это поправил.

Теперь о случае с аплоадом, в Вашем коде почему-то не видно где происходит аплоад файла, а сразу начинается парсинг. Если Вы хотите делать аплоад, то его нужно делать в обработчике post.js, а потом для парсинга уже и для других долгих операций ответветвлять процесс. Вообще, имеет ли смысл ответвлять процесс - это большой вопрос, потому как fork работает не быстро, а новый процесс ест память, так что, если парсинг быстрый (занимает десятки миллисекунд), то нет смысла его форкать, а если это несколько секунд блокирования процесса, то да - тут нужно форкать.

Сделайте скрипт и запустите его или по одной команде запускайте:

#!/bin/bash
sudo apt-get -y install wget
sudo apt-get -y install build-essential openssl libssl-dev pkg-config python
cd /usr/src
sudo wget http://nodejs.org/dist/v4.1.1/node-v4.1.1.tar.gz
sudo tar zxf node-v4.1.1.tar.gz
sudo rm -f ./node-v4.1.1.tar.gz
cd node-v4.1.1
sudo ./configure
sudo make
sudo make install
cd ~
sudo rm -rf /usr/src/node-v4.1.1

npm config set proxy http://user:password@host:8080

Без cluster нода работает на 1 ядре, для масштабирования создаются новые процессы через cluster.fork(); Каждый из процессов может узнать, он главный или дочерний, через cluster.isMaster и cluster.isWorker. Между процессами можно передавать сообщения (события) и сокеты (дескрипторы сокетов). Таким образом, tcp или http сокеты принимаются главным процессом, а на обработку отправляются в один из дочерних. Это в двух словах, подробнее хорошо все написано в доках https://nodejs.org/api/cluster.html

https://www.npmjs.com/package/semver#tilde-ranges-...

По той ссылке, что Вы дали и лежит решение, т.к. на венике могут встречаться файлы и каталоги с разными правами доступа, то нужно выделять из общего потока ошибок EPERM и игнорировать их. Полное игнорирование ошибок: finder.on('error', function (err) {}); Если глушить только EPERM то наверно так:

finder.on('error', function (err) {
    if (err.code !== 'EPERM') finder.stop();
});