Если вы про HTTP, то взгляните на asker — это обертка над http–клиентом Node.js, ориентированная на взаимодействие «сервер ↔︎ сервер». Среди отличительных особенностей как раз возможность использования разных пулов соединений для разных запросов. В комменте вышеmiripiruni привел ссылку на видео, где я чуть-чуть про нее рассказываю.
Если же мы говорим, про пулы TCP соединений, то стоит обратить внимание на модуль jackpot и клиент memcached в качестве примера использования.
И еще немного побрюзжу по поводу нейминга и реализации. То, что вы реализовали традиционно называется connection pool – пул соединений. На качественную реализацию пула соединений на node.js можно посмотреть в стандартной библиотеке node.js: http.Agent. Balancer можно реализовать, используя принципы, что применяются в Агенте:
до лимита соединений создаем новые
ставим обработчики событий соединения, которые приводят к освобождению соединения (ошибки, таймауты, успешные завершения)
по достижении лимита ставим запросы в очередь в пуле
при освобождении соединения проверяем очередь на наличие запросов: если есть — назначаем освобожденному соединению первый
если соединение пришло в состояние, когда его нельзя переиспользовать (ошибка соединения), выбрасываем его из пула
если соединение позволяет указать таймаут простоя (idle timeout) — используем его для удаления соединений из пула, так при отсутствии нагрузки пул постепенно освободится «сам»
Еще можно использовать EventEmitter, как прототип Connect, что добавит изящности, избавит от переопределения метода on() и позволит в обработчиках событий обращаться к экземпляру Connect через this, т.к. обработчики событий в EventEmitter выполняются в контексте экземпляра.
В методе addQuery лучше обернуть вызов _nextTick() в setImmediate, т.к. помимо добавления запроса в очередь будет сразу произведено и выполнение, что не очень хорошо с точки зрения «асинхронного» API. Аналогично я бы поступил с вызовом el.callback(null, result);, чтобы внутренний колбэк таки завершил свою работу (бросил событие drain), а затем уже был вызван пользовательский обработчик.
Можно сразу указыать репозиторий и хэш с именем ветки, тэга или всего чего угодно, что можно передать в качестве аргумента команде git checkout. Например, так:
Демо выглядит интересно, но не более.
Скорее всего, данный проект — конь в вакууме; дюже сомнуваюся я, что это выкидыш реального, живого продукта.
Проект нарушает конвенции экосистемы node.js, на котором построен; я бы на месте разработчиков не попадался на глаза Исааку. Почему было не слепить свои пакеты поверх принятого сообществом и давно уже ставшего официальным npm? Даже в сам проект не удосужились положить package.json с описанием зависимостей, поэтому все зависимости, вместо выкачивания из npm репозитория выкачиваются со своего CDN
Сам node.js, кстати, тоже берется оттуда. Ага, в бинарном виде.
Вышеописанное я не могу списать даже на «early stage» проекта. Создать свою систему распространения на коленке было проще, чем использовать готовую и отлично живущую? :\
Лучшее, что я видел на русском про ООП в JavaScript пару лет назад: dl.dropbox.com/u/3566235/js.zip (сайт автора давно умер, в архиве офлайн копия со схемами и примерами).
Если вы про HTTP, то взгляните на asker — это обертка над http–клиентом Node.js, ориентированная на взаимодействие «сервер ↔︎ сервер». Среди отличительных особенностей как раз возможность использования разных пулов соединений для разных запросов. В комменте выше miripiruni привел ссылку на видео, где я чуть-чуть про нее рассказываю.
Если же мы говорим, про пулы TCP соединений, то стоит обратить внимание на модуль jackpot и клиент memcached в качестве примера использования.
Balancer
можно реализовать, используя принципы, что применяются в Агенте:Connect
устанавливается обработчик событияerror
, который бросает полученное исключение? Реализация EventEmitter в Node.js ведет себя так по-умолчанию, но учитывая домены, например.Еще можно использовать
EventEmitter
, как прототипConnect
, что добавит изящности, избавит от переопределения методаon()
и позволит в обработчиках событий обращаться к экземпляруConnect
черезthis
, т.к. обработчики событий вEventEmitter
выполняются в контексте экземпляра.В методе
addQuery
лучше обернуть вызов_nextTick()
вsetImmediate
, т.к. помимо добавления запроса в очередь будет сразу произведено и выполнение, что не очень хорошо с точки зрения «асинхронного» API. Аналогично я бы поступил с вызовомel.callback(null, result);
, чтобы внутренний колбэк таки завершил свою работу (бросил событиеdrain
), а затем уже был вызван пользовательский обработчик.Ну, и глаз зацепился ;)
«dependencies»: {
«connect»: «git://github.com/senchalabs/connect.git#2.7.5»
}
github.com/meteor/meteor/blob/master/meteor#L47
github.com/meteor/meteor/blob/master/meteor#L57
Скорее всего, данный проект — конь в вакууме; дюже сомнуваюся я, что это выкидыш реального, живого продукта.
Проект нарушает конвенции экосистемы node.js, на котором построен; я бы на месте разработчиков не попадался на глаза Исааку. Почему было не слепить свои пакеты поверх принятого сообществом и давно уже ставшего официальным npm? Даже в сам проект не удосужились положить package.json с описанием зависимостей, поэтому все зависимости, вместо выкачивания из npm репозитория выкачиваются со своего CDN
Сам node.js, кстати, тоже берется оттуда. Ага, в бинарном виде.
Вышеописанное я не могу списать даже на «early stage» проекта. Создать свою систему распространения на коленке было проще, чем использовать готовую и отлично живущую? :\
a.length // 2
var a = [ «a», «b», null ];
a.length // 3