Comments 26
Не думаю, что это будет удобнее, чем websocket. К тому же в данном случае, мы ограничены только одним consumer'ом
сравнивать amqp и websocket — тоже самое что солдата и балерину. Кто-то умеет танцевать, а кто-то стрелять.
тем более, что одно транспорт, а второе протокол/формат обмена данными :) AMQP через веб-сокеты это самое оно (хотя во многих случаях и STOMP достаточно). тем более что все основные MQ брокеры уже заявили что поддерживают WS как транспорт (ActiveMQ и JBoss HornetQ)
в HornetQ транспортный уровень (коннекторы которые, если я верно помню) работает на базе фреймворка netty, да, и уже давно. теперь можно просто в конфиге указать что использовать ws и все. а так конечно, оно через netty работает как и все остальные сетевые вещи
нет, это планируется сл. этапом.
пока идет только обкатка сервера

в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.
IMXO. тут трудно спорить, судя ГОСТУ — они оба синхронные:
Basic.Consume (ID=10) start
a queue consumer: Sync request, carries content
Basic.Get (ID=80) direct
access to a queue: Sync request, carries content

но по своей сущности Consume — синхронный запрос, как только сообщение появляется в очереди, оно сразу считывается (передается клиенту), коннекция держится постоянно. в этом смысле — синхронный.
методом GET ты можешь забрать сообщение в любое время из очереди (или пустое уведомление GET-EMPTY). коннекцию постоянно можно не держать. в этом смысле — асинхронный. Хотя если смотреть с иной стороны, как только мы выдаем GET, мы сразу получаем (синхронно) ответ: либо GET-OK либо GET-EMPTY, т.е. синхронный.
честно говоря хз
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,

я не в том смысле, я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно? если плодить потоки — то и 1к коннектов будет сложно обработать
или я неправильно понял?

ps: я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем.
я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно?
libevent библиотека с асинхронным ввод/выводом, т.е. использует неблокирующие сокеты. Все работает в одном потоке, только параллельно: как только приходит запрос на сокет, создается буфер и его начинает обрабатывать кэллбэк, если пришел еще один запрос, то новый буфер начинает обрабатывать следующий кэлбэк, если ответ от брокера не пришел, т.е буфер пуст, переходим к обработке следующего буфера и так проходимся по цепочке всех синициированных буферов. По окончанию работы кэлбека — буфер отдается в сокет и освобождается.

и вот еще одно мнение: amix.dk/blog/post/19414
поллинг проще реализовывать и масштабировать. Из всего что я видел, я сделал вывод – все Comet решения слишком уж хакерские, изворотливые и очень тяжело масштабируются. Они плохо масштабируются, потому что web платформы построены на модели запрос-ответ.

я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем
интересно посмотреть
ну если работа с синхронным методом асинхронная, тогда вопрос снимается ;)

см приват
идея состоит в следующем: прокси принимает сообщения amqp и складывает их во внутренние очереди (массивы) сообщений, а при подключении http клиента — проходит по всем внутренним очередям и отдает клиенту только те сообщения, которые нужны данному пользователю
а как конкретно фильтровать — прокси спрашивает по amqp у демона отвечающего за БД.

т.е. не просто трансляция amqp-http а прокси со своей бизнес логикой.
хм. кролик = rabbitmq
это и ежу понятно
для websockets у меня отдельная прокся ;)
а куда эта прокся ведет?
у меня 1300 rps на ноуете 2.3 GHz 1Mg, но этого должно вполне хватить для обработки 10к
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.
Only those users with full accounts are able to leave comments. Log in, please.