<div class="gmail_quote">I think pausing would be acceptable, possibly something that could be prototyped/investigated via a plugin?</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, May 24, 2012 at 12:37 PM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 24/05/12 11:33, Brendan Hay wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Good stuff!<br>
<br>
The physical layout comment is regarding having to specify -sname/-name<br>
in the x-ha-policy .. ie having clients aware of the nodes that compose<br>
a cluster.<br>
In the imaginary places in my head it would be nicer to set something<br>
along the lines of 'one slave', 'two slaves', ..., or '50% of the<br>
cluster has slaves' etc.<br>
</blockquote>
<br></div>
Oh, of course. Yes, I want that to happen too. Basically clients should not have to know anything about how the server / cluster is configured.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Migrating/moving a queue around inside a cluster is another nice to have<br>
- scenario would be whatever you're using to do load-balancing<br>
throws a nana and causes too many queues to be declared on a single<br>
machine vs a more desired even spread. Basically fine tuning your queue<br>
distribution, on the fly.<br>
</blockquote>
<br></div>
For mirrored queues that's conceptually quite easy; add some mirrors, wait for them to catch up, remove the old ones and you're done.<br>
<br>
For non-mirrored queues this would be fairly horrible... unless you're happy for the queue to pause while data is migrated.<div><div><br>
<br>
Cheers, Simon<br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</div></div></blockquote></div><br>