[rabbitmq-discuss] mirrored queue cluster

[Tim Watson]

Hi,

On 5 Oct 2013, at 16:48, PATAR, SAGAR wrote:
> The requirement we have is a simple JMS topic with failover and persistency.. 
> Where multiple client subscribe for the messages and when a new client is introduced NO changes in framework as  the Topic is already configured for failover and persistence ..the new client will just make a connection and start consuming ..
> 

You are conflating queues and topics here, which is hardly surprising given that you're coming at this from a JMS perspective, but still. In AMQP, there is no such thing as a topic, however there is such a thing as a topic exchange, which routes to specific queues based on matching between a message routing key and the pattern that was used to bind a queue to an exchange. A topic exchange then, will route the same message to multiple queues, if the bindings in question match the routing key.

> With RabbitMQ my understanding is we need to configure a new queue and mirror it and then ask the new client to consume the message ...??
> 

You need to bear in mind that mirroring only applies to queues, and topics do not exist as an entity that holds messages. So you're right in one sense, because you can only mirror queues and in order to filter subscriptions based on routing key, you will need multiple queues bound to a topic exchange.

> Pl. check slide 3 and  4 in the attachment ... For new client do we need to configure a new mirrored queue ... All the queues should get all the messages from the exchange ...
> 

If that client wishes to get a copy of each message, then yes, you will need to add another queue. If you did not, messages in a single queue would be delivered to clients in a round-robbin fashion, so not all clients would see all messages.

> On oct 5, 2013, at 12:54 a.m., "PATAR, SAGAR" <sp345s at att.com> wrote:
> 
>> But still we have to manage all the mirror configurations of all the separate queues per client .. and also when a new client is introduced we have to change our configuration to create a new queue and then mirror it etc ....right
> 

Yes and no. When you declare a queue using AMQP, it will only be created if it does not already exist, so your client can simply declare the queue whenever it starts up. Mirroring for queues is controlled by policy, so you can ensure that whenever your queue is first created, an HA/Mirroring policy will be automatically applied to it.

On 7 Oct 2013, at 15:11, PATAR, SAGAR wrote:
> 1)The consumer can simply subscribe BUT there is NO way the dynamic queue is mirrored and also if the consumer has a downtime then the messages published during the downtime will be lost as the dynamic queue will be deleted .. Even if there is a feature where the dynamic queue is not deleted when the connection fails .. Can we mirror that queue and also how can we make sure when the client reconnects will it be using the same queue or will create a NEW queue...
> 

As I said, mirroring can happen automatically if an administrator configures the relevant policies on the broker.

> 2)If we need to mirror the queue the new consumer is going to consume from then we might have to do some confutation changes ..right??
> 

No, the policy will be applied automatically when the queue is first created.

> " Note that I was explaining things in AMQP 0-9-1 terms, and now you've revealed that your
> requirements are framed in JMS terms, which are not exactly the same." ..
> Can we use Rabbit to achieve the JMS based requirements ??

Yes, I should think so, however...

> -----Original Message-----
> From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Michael Klishin
> Sent: Monday, October 07, 2013 9:41 AM
> To: Discussions about RabbitMQ
> Subject: Re: [rabbitmq-discuss] mirrored queue cluster
> 
> Unfortunately, I'm not familiar with how vFabric Rabbit's JMS client maps RabbitMQ protocol
> to JMS.


I must admit that I haven't looked at how the RabbitMQ JMS client maps queues and exchanges to Topics. However the entities we've discussed thus far are all AMQP based, so some kind of mapping ought to be possible.

HTH

Cheers,
Tim