Утечки безусловно есть, но воркеры сами плавно перезапускаются при достижении заданного порога памяти, так что это не проблема и работает месяцами стабильно.
Думаю, Твиттер явление временное. Да еще и со скудным функционалом… Twitter не может составить конкуренцию Google. Хотя купить конечно стоило за копейки еще давно, ради пиара… а теперь уж точно не стоит покупать.
В MongoDB и используются Tailable cursors. sleep там виртуальный.
> Хоть тресни, но сама монга нам не пошлет ивент о своем изменении.
Пошлет, в последних версиях ввели awaitCap. Однако мне не удалось завести. Демон это поддерживает.
> Красивее делать get пачкой для всех ожидающих клиентов в самом воркере, потом спуск значения до конечного пользователя.
Ну так и происходит вообще-то ;-) 1 висящий запрос к базе данных, и «спуск» событий сессиям. Всё на уровне приложения.
Весьма универсальным решением является хранение в MongoDB коллекции sessions с текущими подключениями, вида {userid: ..., workerId: ..., connId: ...}, где workerId — уникальный ID приложения задаваемый в onReady(), а connId — ID текущей сессии, userid — идентификатор пользователя.
И при отправке события пользователю необходимо выбрать все активные сессии данного пользователя, и вставить в коллекцию events событие с двумерным массивом связок workerId/connId. А каждый воркер слушает предназначенные ему события через tailable cursors по workerId и направляет уже клиентам. Это просто летает. Я на такой схеме сделал чат как на фейсбуке с мгновенной синхронизацией между несколькими броузерами.
throw new OloloException;
> Хоть тресни, но сама монга нам не пошлет ивент о своем изменении.
Пошлет, в последних версиях ввели awaitCap. Однако мне не удалось завести. Демон это поддерживает.
sleep? О чем Вы?
> Красивее делать get пачкой для всех ожидающих клиентов в самом воркере, потом спуск значения до конечного пользователя.
Ну так и происходит вообще-то ;-) 1 висящий запрос к базе данных, и «спуск» событий сессиям. Всё на уровне приложения.
И при отправке события пользователю необходимо выбрать все активные сессии данного пользователя, и вставить в коллекцию events событие с двумерным массивом связок workerId/connId. А каждый воркер слушает предназначенные ему события через tailable cursors по workerId и направляет уже клиентам. Это просто летает. Я на такой схеме сделал чат как на фейсбуке с мгновенной синхронизацией между несколькими броузерами.