Good stuff!<div><br></div><div>The physical layout comment is regarding having to specify -sname/-name in the x-ha-policy .. ie having clients aware of the nodes that compose a cluster.</div><div>In the imaginary places in my head it would be nicer to set something along the lines of 'one slave', 'two slaves', ..., or '50% of the cluster has slaves' etc.</div>
<div><br></div><div>Migrating/moving a queue around inside a cluster is another nice to have -�scenario would be whatever you're using to do load-balancing�</div><div>throws a nana and causes too many queues to be declared on a single machine vs a more desired even spread. Basically fine tuning your queue distribution, on the fly.</div>
<div><br></div><div>Thanks,</div><div>Brendan</div><div><br><div class="gmail_quote">On Thu, May 24, 2012 at 12:02 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 class="im">On 24/05/12 09:47, Brendan Hay wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yo!<br>
<br>
There's been a few hints dropped here towards future changes in<br>
Federation, Mirrored Queues, and making things a bit more transparent to<br>
clients regarding physical topology layout.<br>
<br>
Do you dudes have some sort of non-committal timeline/roadmap to share?<br>
(Off the record is fine, we won't hold you to anything.)<br>
</blockquote>
<br></div>
Matthias always hates it when I make any sort of forward looking prediction. But I'm in an uncooperative mood today, so here we go. All remarks here are extremely tentative and should not be taken as any sort of guarantee of anything happening.<br>
<br>
There will probably be a 2.8.3 release soon, with bug fixes only.<br>
<br>
2.9.0 should happen at some point in the summer (for a broad definition of summer). Some of the more major new things we're hoping to do include:<br>
<br>
* Take federation configuration out of the config file and make it dynamically changeable with rabbitmqctl / mgmt<br>
<br>
* Stop federation from being an exchange type, make regular exchanges federated through dynamically changeable policy managed by the sysadmin<br>
<br>
* Similarly, make HA status of queues manageable dynamically by the sysadmin, not statically by the application programmer<br>
<br>
* Rework clustering commands to make clustering clearer and less error prone<br>
<br>
Although obviously I can't guarantee that all of these will be in 2.9.0 (or will ever happen; plans are constantly shifting). But those are the big things I want to see (along with lots of smaller features and bug fixes I'm sure).<br>
<br>
By the way, what do you mean by "making things a bit more transparent to clients regarding physical topology layout"?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm personally interested in things such as dynamic upstream_sets, a<br>
better mechanism for specifying x-ha-policy to a subset, moving<br>
master/declared queues around inside a cluster and things related to<br>
making RabbitMQ more manageable in higher throughput scenarios.<br>
</blockquote>
<br></div>
Hopefully you should get many of these.<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br></div>