[rabbitmq-discuss] Clustered startup with multiple queues and multiple masters

[Matt Pietrek]

Wow, great turnaround time. Thanks!

> As a curiosity, how are you waiting to be sure that the messages are
persisted?

I'm using transactions.

For what it's worth, this hang on broker start is happening much less than
10% of the time. It happened twice in 10 minutes one day, and the next day
didn't happen at all.

For what it's worth, I now have Mnesia logging enabled so that if/when it
does repro again, I'll have more details.

Matt


On Thu, Jun 21, 2012 at 10:53 AM, Francesco Mazzoli
<francesco at rabbitmq.com>wrote:

> Hi Matt,
> At Thu, 21 Jun 2012 09:05:05 -0700,
> Matt Pietrek wrote:
> > Thanks Francesco.
> >
> > Your script looks reasonably close to what I'm doing, except for a
> > couple of key differences:
> >
> > All of your nodes are running on the same host. In my setup, each
> > node is in its own VM. I imagine this introduces additional
> > networking into the communication between nodes.
>
> Yeah. I'm on my laptop these days, so if anything I'll a VM setup on
> Monday.
>
> > When you start Rabbit instances, you're doing it sequentially. In my
> > setup I start up in parallel on all three VMs via Capistrano. If you
> > can't go the multi-VM route, you may be able to somewhat simulate
> > this by starting the instances with an '&' at the end.
>
> Well, I'm forking them one after the other and then waiting for them
> to actually start, so is not that sequential. I doubt that matters.
>
> > I use "killall -9 beam.smp", rather than just "killall beam.smp"
>
> Right. This should not make much of a difference either. I tried with
> -9 and things were OK.
>
> As a curiosity, how are you waiting to be sure that the messages are
> persisted? I am using publisher confirms, see
> http://www.rabbitmq.com/extensions.html - that's why puka and not pika
> - but you need to make sure of that, otherwise you can get message
> loss or other strange behaviours.
>
> If you are trying to simulate what happens when the system crashes
> while sending messages, then it's different and of course you can't
> rely on any of the messages in being there when you restart them - but
> that does not justify the behaviour you're seeing anyway.
>
> Francesco.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120621/1b1f4b59/attachment.htm>