I'm not sure exactly what you mean by "exchanges" on clients, but I'll
throw something out anyway.

I'm assuming that you've got one broker (you call 'server A') in a
central location/public IP.  You have a queue on this broker that holds
messages pertaining to a topic and you want those messages delivered to
each of a number of clients that may come and go from time to time.

In this case, I would recommend using a single queue, probably with a
ring policy to ensure it doesn't get too big.  The queue should be set
to "browse-only" so no single consumer removes any messages.  Messages
are only removed from the queue when they expire TTL or when the queue
reaches its size limit.

Now, when a new consumer subscribes to the queue, all the messages will
be delivered immediately and any new messages will be delivered as they
arrive.  This will be true independently for each subscriber to the queue.

Now, if by 'exchanges' you mean that the 'clients' are actually brokers
in a federation relationship, this will work as well.  In this case, the
queue subscribers aren't end clients but an exchange on the downstream
broker that can route the messages any way they see fit.  This will
require queue-routes in the federation.

I hope this helps,

-Ted

On 05/23/2014 09:18 AM, Tor Rune Skoglund wrote:
> Hello List,
> 
> we want to bind an outgoing queue on server A to a number of exchanges
> on a number of clients devices. It is not guaranteed that every single
> client is online when the binding happens. In that case, we want those
> clients that actually are online to receive the messages in that queue
> asap, and the rest of clients get their exchanges to bind automatically
> when they get online (and then start receiving the messages in that queue).
> 
> Is this controllable from the server side, e.g. by using QMF to
> configure the remove exchanges when the client device actually gets
> online? Any pointers to how to do this?
> 
> The queue should auto-delete when _all_ those client devices have
> received the messages (or when the message times out due to ttl).
> 
> The client devices might live "everywhere" on the net, might change IP
> addresses from connection till next connection, and could be on LANs
> (i.e. NAT'ed), so it is always the client that initiates the TCP
> connection to the server.
> 
> Appreciate any input on how to solve this! :)
> 
> - Tor Rune Skoglund, [email protected]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to