qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Whether to use Queues or Topics.. ?
Date Fri, 05 Oct 2012 08:50:48 GMT
I guess that a key point to have in the back of ones mind is that the 
JMS Concepts of topic and queue are really mappings on to AMQP in Qpid.

By that I mean in AMQP there are concepts of exchanges, queues and 
bindings between the exchange and queue - and consumers *always* receive 
their messages off a queue whether they know it or not. So a 
*traditional* JMS topic would use the topic exchange and (under the 
hood) an exclusive autodelete queue who's name is automagically 
allocated by the broker (If you create a topic subscription and do 
qpid-config queues and qpid-config -b queues you should see this more 
clearly), so say for three subscribers to a topic you'd see three queues.

The qpid Address String syntax gives an awful lot more control and 
nuance - I must admit that I always tend to use quite explicit Address 
Strings these days even if I'm doing simple stuff.

Rajith's response is a great starting point, but do have a look at the 
Programming In Apache Qpid online book, that has a section on the 
Address String syntax. There are a few examples (could probably do with 
a few more covering more sophisticated use cases) but if you are 
comfortable with BNF you should be able to uncover a whole world of 
wonderment :-) The Address String is probably worth a book in itself - 
it's really powerful but the documentation is a little disjoint, for 
example IIRC you can do things like change prefetch configuration for 
particular sessions just using the Address String.


On 02/10/12 14:45, Rajith Attapattu wrote:
> Sajith,
> As Phil mentioned, using durable subscriptions is one way of doing it.
> You could also use Queues in this case as long as you use 1 queue per node.
> When your "client" sends a message it will end up in all the nodes
> "interested" in your message.
> Lets say you send a message to the following address "amq.topic/abc"
> ... "abc" here is the subject and is mapped to the routing key in AMQP
> 0-10.
> If you have nodes with queues bound to amq.topic with binding key
> "abc" then all of them will get the message.
> Your nodes can have the following address when they create their subscriptions.
> "node1; {create: always, durable: true,
> x-binding:{exchange:'amq.topic', key:abc}}"
> This address will create a queue named "node1", mark it as durable and
> then bind it to the amq.topic exchange using the key 'abc'.
> If you don't want the messages to survive a server restart then you
> can ommit the durable flag.
> Hope this helps.
> Regards,
> Rajith
> On Tue, Oct 2, 2012 at 7:35 AM, Phil Harvey <phil@philharveyonline.com> wrote:
>> Have you considered JMS durable subscriptions?
>> They are described here:
>> http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/basics.html
>> On 2 October 2012 11:43, Sajith Kariyawasam <sajhak@gmail.com> wrote:
>>> Hi all,
>>> My requirement is to notify a cluster of nodes, when an event is occurred..
>>>   nodes will be different based on client Id, one client can have more than
>>> one node...
>>> In message broker, I will have one queue per client (Say queue1, queue2.. )
>>> , and nodes will be listening to their relevant queue ... so, in this case
>>> more than one node (say node1, node2 and node3) listening to one queue
>>> (Say, queue1)
>>> I realize that if one node(say node1)  reads the message from the queue,
>>> the message is gone, so that the other nodes (node1 and node2) will not be
>>> notified..
>>> Hence I thought of using Topics instead.. but there the problem I face is
>>> that the messages published on topics are not persisted, if one node misses
>>> a message (that node may be down at the time of message receiving) it never
>>> gonna get the message again (if the node is rebooted)..
>>> Are there any other construct that I can use or a combination of Queues and
>>> Topics for my use case?
>>> --
>>> Best Regards
>>> Sajith
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message