[rabbitmq-discuss] Clustering Question

Fri Jun 5 17:25:02 BST 2009

On Jun 5, 2009, at 9:11 AM, Jason J. W. Williams wrote:

> Hi Hugh,
>
> Queue data is not replicated to other members of the cluster  
> (whether it's a persistent or non-persistent queue), so if a cluster  
> member dies, all queue data goes poof if it's non-persistent.  
> However, if it is persistent, while queue data doesn't go poof  
> (still in the log) when you restart the node the queue data won't  
> auto replay into the cluster.  You'll have to do that manually.

Are you saying that if an instance of RabbitMQ does down and is  
brought back up, its persistent messages won't be delivered when a  
consumer re-attaches?  (I'm not sure what you mean by "manually".)

If that's the case, that seems quite broken and not fault-tolerant at  
all.

Surely, I'm misunderstanding.....

I so need to get out from under my workload and write some tests.

Keith

>
> -J
>
> On Fri, Jun 5, 2009 at 8:07 AM, Hugh Watkins <hwwatkins at gmail.com>  
> wrote:
>
> I was trying to understand how the clustering support works in  
> RabbitMQ
>
> 1) From the documentation the message queue data is not clustered,  
> so if you have queue created on one machine and the queue is not  
> persisted then that box going down will cause the queued messages to  
> be destroyed. Is this a correct interpretation?
>
> I have a system that is creating perishable queue messages, i.e.  
> they need to be acted on in 100-200 ms or it's to late a timeout  
> will occur further up the chain.  I would like to setup a cluster an  
> protect as many messages as possible.  It would not be worth  
> creating a persistent queue  because it would slow down the  
> processing and as I mentioned these are perishable messages.
>
> It seems like I should create different queues on each machine in  
> the cluster and try to load balance across those queues, either by  
> having the producers write too the local queue, round robin or some  
> other mechanism.  The workers in turn would listen on all queues.   
> Does this sound reasonable?  It requires more configuration than I  
> was hoping for because at least the workers have to be aware on  
> another queue being created if another node is added.
>
> Thanks,
> Hugh
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090605/8b8caa9d/attachment.htm 