AMQP-REST

[@vsviridov]

Интересно, нужно будет попробовать.

[@AndrewStephanoff]

Не думаю, что это будет удобнее, чем websocket. К тому же в данном случае, мы ограничены только одним consumer'ом

[@akalend]

сравнивать amqp и websocket — тоже самое что солдата и балерину. Кто-то умеет танцевать, а кто-то стрелять.

[@aleks_raiden]

тем более, что одно транспорт, а второе протокол/формат обмена данными :) AMQP через веб-сокеты это самое оно (хотя во многих случаях и STOMP достаточно). тем более что все основные MQ брокеры уже заявили что поддерживают WS как транспорт (ActiveMQ и JBoss HornetQ)

[@AndrewStephanoff]

хмм… я думал это netty поддерживает websocket, а не hornetq

[@aleks_raiden]

в HornetQ транспортный уровень (коннекторы которые, если я верно помню) работает на базе фреймворка netty, да, и уже давно. теперь можно просто в конфиге указать что использовать ws и все. а так конечно, оно через netty работает как и все остальные сетевые вещи

[@AndrewStephanoff]

с чего вы решили, что я сравниваю websocket с amqp? я сравниваю websocket и rest.

[@akalend]

надо присмотреться к websocket
спасибо за комментарий.

[@slayerhabr]

насколько я понял чтение сообщений через long-poll?

[@akalend]

нет, это планируется сл. этапом.
пока идет только обкатка сервера

в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.

[@AndrewStephanoff]

Basic.Get — синхронный метод
Basic.Consume — асинхронный

[@akalend]

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, т.е. синхронный.

[@akalend]

блин прочитал что написал и сам запутался…

[@slayerhabr]

а как будут синхронные запросы обрабатываться на 10к коннектов?

[@akalend]

честно говоря хз
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,

[@slayerhabr]

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

ps: я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем.

[@akalend]

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

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

и вот еще одно мнение: amix.dk/blog/post/19414

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

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

интересно посмотреть

[@slayerhabr]

ну если работа с синхронным методом асинхронная, тогда вопрос снимается ;)

см приват

[@akalend]

ссылку посмотрю,
спасибо

[@slayerhabr]

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

т.е. не просто трансляция amqp-http а прокси со своей бизнес логикой.

[@akalend]

да, интересно. а брокер какой, ActiveMQ?

[@slayerhabr]

кролик

[@akalend]

а кролик Websockets поддерживает? плагин?

[@slayerhabr]

хм. кролик = rabbitmq
а зачем ему websockets? для websockets у меня отдельная прокся ;)

[@akalend]

хм. кролик = rabbitmq

это и ежу понятно

для websockets у меня отдельная прокся ;)

а куда эта прокся ведет?

[@akalend]

у меня 1300 rps на ноуете 2.3 GHz 1Mg, но этого должно вполне хватить для обработки 10к
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.