On 02/05/2014 09:52 PM, Justin wrote:
Thank you for your response. I think I’m missing something fundamental here,
but I’m close to grasping it.
In reading the exchange ‘subtype’ stuff here
<http://qpid.apache.org/components/java-broker/book/Java-Broker-Concepts-Exchanges.html>
(in Java because there is nothing in C++ documentation about it), they all
look like they inherently support publish-subscribe many-to-many type
messaging and they just differ on the method of distribution to the
receivers.
Exactly right.
I am concerned that if I use a topic of any type, the receiver would miss a
message if it wasn't listening when the message was sent. I gained that
understanding because in the c++ documentation here
<http://qpid.apache.org/releases/qpid-0.24/programming/book/section-addresses.html>
, it says, "Topics deliver messages immediately to any interested receiver,
and do not store messages. Because there were no receivers at the time spout
sent the message, it was simply discarded".
In general that is true, however you can have a named subscription that
stores messages even when the consumer is not actually connected. E.g.
using an address like:
amq.fanout; {link:{name:sub1,durable:true}}
or
amq.fanout; {link:{name:sub1,reliable:at-least-once}}
and after the first time you create the receiver, subsequent messages
will be stored up if the receiver is not active at the time of
publishing and it will receive them when it reconnects. Note that you
need to be careful that messages don't start piling up when a subscriber
fails to reconnect.
You can have multiple such subscribers, you just need to pick a
different name for each of them.
In my current system, I have a three use cases:
- Pub/Sub - Intend to use 'topic' so these information messages do not
accumulate. I.e. the publisher is writing them at 20hz and the receiver only
needs 10hz
- A request reply schema: These scenarios are one-to-one or many-to-one,
so a standard queue is acceptable.
- A command schema: This is where my issue is. I might need to issue a
command to multiple receivers and need to know that they will 'queue' up at
the receiver for all available receivers. Topics as defined in the c++ API
document won't work. They might work as written in the Java documentation
...
I'm beginning to think my misunderstanding is that the I thought type of
sender and receiver need to match. I.e. if I publish a topic, I must receive
one. Is this not true? i.e. to solve the last use case, do I need to have
the sender use node type topic and the receiver use node type queue (and not
use the assert option, obviously)?
You only need to specify the node type if you want the queue or topic to
be created on demand.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
