qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: 2 Client Question: Multiple Receivers & Aborting fetch()
Date Wed, 05 Feb 2014 22:20:54 GMT
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message