[rabbitmq-discuss] RFC - new exchange type idea

Alexis Richardson alexis at rabbitmq.com
Wed Apr 18 12:42:53 BST 2012


I'm in favour of anything that makes it easier to get started.

I am continually surprised to hear things like "rabbit has queues but
not pubsub" as well as "rabbit is good for pubsub but not queues".
Not to forget "rabbit does not do persistence" as well as "rabbit is
best for persistence" and of course "rabbit uses mnesia for message
persistence" when it doesn't.  In addition all kinds of FUD gets slung
about.

The Redis community has been great at innovating from the bottom
upwards, to deliver simplicity.   This is immediately visible when you
look at the slew of MQ-alike layers that people have created.  These
tend to focus on the core functions of pubsub, queue, and sometimes
1-1 and/or RPC; while ignoring eg flow control, paging, and other
features.  Some layer a work queue system on top of Redis, like
Celery.  Resque is a good example of that.

Here are more examples:

http://thechangelog.com/post/6791886560/thoonk-py-persistent-and-fast-push-feeds-queues-and-jobs
("a project that takes a unified approach to feeds, jobs, and queues,
all with a Redis backend." and looks a lot like rabbit)

https://github.com/djhworld/redis-mq  ("I felt tools like the
excellent RabbitMQ were too complex for small projects like the ones I
tend to make.")

https://github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
(WCF for hipsters)

http://restmq.com/ ("There are HTTP clients for pratically all
languages. That's all that it takes to use RestMQ within your
application. No special protocols or strategies, just dynamically
created queues.")

http://lumberjaph.net/perl/2010/04/14/presque-a-redis-tatsumaki-based-message-queue.html
("a small message queue service build on top of redis and Tatsumaki.
It’s heavily inspired by RestMQ and resque.")

http://flask.pocoo.org/snippets/73/ ("if you just want a very basic
queue functionality to get started")

https://github.com/josiahcarlson/rpqueue (priority queue)

All of these projects are motivated by ease of use and a simple API.
Let's make Rabbit easier to use.

alexis




On Wed, Apr 11, 2012 at 5:36 PM, Jason J. W. Williams
<jasonjwwilliams at gmail.com> wrote:
> I think this is a great idea. It makes it easier to on onboard those who initially need a simple message queue and end up using Redis. Whatever message queue tech people start with for their first quick and dirty needs they tend to stick with. So I think this is a great idea for getting folks converted to Rabbit early.
>
> Yes functionally anonymous queues function the same way, but conceptually they break the idea exchanges are where you publish messages since you supply the "empty" exchange.
>
> Whether its a new exchange type or a change to the library API for anonymous queues, I like the direction Alvaro's going for folks getting their feet wet.
>
> -J
>
> Sent via iPhone
>
> Is your email Premiere?
>
> On Apr 11, 2012, at 7:13, Alvaro Videla <videlalvaro at gmail.com> wrote:
>
>> Hi,
>>
>> I've been thinking on creating a new exchange type whose goal will be to simplify the ways messages are routed to queues.
>>
>> So now for example to publish a message to a queue I need to do something like:
>>
>> $ch->exchange_declare('foobar', 'direct');
>> $ch->queue_declare('foobar');
>> $ch->queue_bind('foobar', 'foobar');
>> $ch->basic_publish($msg, 'foobar');
>>
>> I want to be able to do this:
>>
>> $ch->exchange_declare('foobar', 'new-exchange-type');
>> $ch->basic_publish($msg, 'foobar');
>>
>> So that means that by declaring a "foobar" exchange with the new type I will bind a new queue to that exchange during exchange creation on the broker side.
>>
>> The queue will have similar durability properties as the exchange.
>>
>> The exchange won't accept binding requests, so 1 exchange of that type will only have 1 queue bound to it.
>>
>> The idea is also to not perform any query while searching for a queue where to route messages, so routing speed *should* be a bit faster than a normal direct exchange.
>>
>> The exchange should act basically as a direct exchange.
>>
>> Then as a user of RabbitMQ that just want to have a queue server for delayed jobs this is the most basic setup I think you can have.
>>
>> BTW, I know you can publish messages to the anon exchange by using the queue name as routing key, but this requires that particular knowledge of AMQP.
>>
>> What do you guys think?
>>
>> -Alvaro
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


More information about the rabbitmq-discuss mailing list