<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Dec 19, 2008 at 8:11 AM, Ben Hood <span dir="ltr"><<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> 2) What would be the right way of upgrading rabbitmq on a running server<br>
> without shutting it down? (I know erlang supports this feature but I failed<br>
> to find something about it in the documentation).<br>
<br>
</div>This is supported in Erlang and I use it a lot myself when hacking on<br>
Rabbit but we are not yet making use of it from a release perspective.<br>
One of the issues that you would run into (which is not necessarily<br>
Erlang specific) is dealing with schema upgrades in mnesia, i.e. you<br>
would have to migrate the database (which changed considerably between<br>
1.4 and 1.5). I should imagine that as Rabbit matures more, we could<br>
make more use of this feature.<br>
<br>
Having said that, I know that Edwin is using OTP release handling with<br>
Rabbit, whereas the official Rabbit release management is more OS<br>
package manager centric, so he may be able to comment on this.</blockquote><div><br>So, what would be my course of upgrade in a running server? Stop rabbit, upgrade and start it again and it should upgrade the mnesia-db?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<a href="http://hopper.squarespace.com/blog/2008/11/9/flow-control-in-rabbitmq.html" target="_blank">http://hopper.squarespace.com/blog/2008/11/9/flow-control-in-rabbitmq.html</a> </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
"From a protocol perspective, when the broker decides that it is<br>
running out of resources to buffer an imbalance, it sends a<br>
channel.flow command out to every channel. This command contains a<br>
flag to indicate to a client whether content bearing AMQP methods can<br>
be sent or not. So if a client receives this command with the flag set<br>
to false, then the client should suspend sending any further content<br>
bearing methods (e.g. basic.publish), until such a time that the<br>
broker notifies the client that it is safe to resume. The notification<br>
of resumption is the opposite of the pause - the broker sends a<br>
channel.flow command with the flag set to true."<br>
<br>
<font color="#888888"></font></blockquote><div><br>Thanks for the info and the link. I'll read more about it.<br><br>Eran <br></div></div><br></div>