[rabbitmq-discuss] RabbitMQ 1.5.0 released

Fri Dec 19 06:11:25 GMT 2008

Eran,

On Fri, Dec 19, 2008 at 3:06 AM, Eran Sandler <eran.sandler at gmail.com> wrote:
> 1) Have you managed to test the memory based flow control feature on Windows
> prior to the release?

I'm not aware of any Windows specific testing of this feature -
Matthias may have done though - but if you'd like to test this, we'd
be very interested in your mileage.

> (it wasn't mention in the documentation like the
> MacOSX issue)

Personally I don't think there is an OS X issue per se (yet). The
reason why there is an official cautiousness about how this is handled
on OS X (and any other non-Linux OS) is because of the problems that
we ran into when running this on Linux. When we originally tested this
feature, everything was fine. However, we tested this on a server that
coincidentally was not doing much disk IO at the time. Since Linux
uses free memory to cache disk IO, the amount of free memory reported
by the standard Erlang tools was misleading and the alarm was being
sounded too easily. So we wrote a Linux specific memory supervisor to
get a more accurate reading from /proc/meminfo. We also turned this
feature off by default, because we felt that it would confuse people
in a dev scenario but still want to allow this to be turned on in a
prod scenario (which is where you need it most).

The length that we had to go to get this to work properly on Linux
indicates that there may be some other memory specific idiosyncrasies
on other OSs, which we have not analyzed in full detail.

Matt Stancliff started a discussion thread recently about his
experiences on OS X and the specifics of memory reporting on that
platform, so essentially we are waiting to hear back from similar
experiences from users on different platforms.

> 2) What would be the right way of upgrading rabbitmq on a running server
> without shutting it down? (I know erlang supports this feature but I failed
> to find something about it in the documentation).

This is supported in Erlang and I use it a lot myself when hacking on
Rabbit but we are not yet making use of it from a release perspective.
One of the issues that you would run into (which is not necessarily
Erlang specific) is dealing with schema upgrades in mnesia, i.e. you
would have to migrate the database (which changed considerably between
1.4 and 1.5). I should imagine that as Rabbit matures more, we could
make more use of this feature.

Having said that, I know that Edwin is using OTP release handling with
Rabbit, whereas the official Rabbit release management is more OS
package manager centric, so he may be able to comment on this.

> 3) Can you elaborate more on the memory based flow throttling and what is
> the behavior of clients when they get the channel.flow command?

Have you read this article?

http://hopper.squarespace.com/blog/2008/11/9/flow-control-in-rabbitmq.html

"From a protocol perspective, when the broker decides that it is
running out of resources to buffer an imbalance, it sends a
channel.flow command out to every channel. This command contains a
flag to indicate to a client whether content bearing AMQP methods can
be sent or not. So if a client receives this command with the flag set
to false, then the client should suspend sending any further content
bearing methods (e.g. basic.publish), until such a time that the
broker notifies the client that it is safe to resume. The notification
of resumption is the opposite of the pause - the broker sends a
channel.flow command with the flag set to true."

HTH,

Ben