[rabbitmq-discuss] of queues, memory and heartbeats...
tonyg at lshift.net
Tue Sep 1 12:19:11 BST 2009
> 1. Even though we haven't explicitly enabled it, if we do start to
> see channel_flow messages, this would be the memory based
> throttling, correct?
That's right. Individual client libraries need to be altered to cope
with unsolicited "channel.flow" messages.
> 2. Besides rabbit noticing when a TCP connection dies - is there any
> "heartbeat" functionality built into rabbit and/or the AMQP spec
> that would actually test whether or not a connection is active,
Yes, there's a heartbeat parameter negotiated as part of the
"connection.tune"/"connection.tune-ok" sequence at connection startup.
It's pretty loosely defined, but basically if there's no activity for N
seconds, a peer may decide the connection has collapsed and may close
> and if it isn't, kill the relevant queues?
This is independently controllable: if the queues were marked exclusive
when declared (see the spec's documentation around "queue.declare"),
then when the connection goes, so will the queues. Autodelete works
similarly, but at consumer granularity rather than connection granularity.
> Do I as the person who
> monitors the server configure this, or do the programmers who
> write our clients need to incorporate something into their code?
Interesting question. The server at the moment does not have a mechanism
for suggesting the use of a heartbeat to its clients: it is up to
clients to configure the heartbeats they feel they need. This could be
changed, a little, so that the server could suggest a value, but the
clients would still be free to override the server's suggestion.
Negotiation in AMQP is a bit screwed up, to be honest: most of the
protocol is great, but negotiation is a bit weak. TELNET has the right
 Tony Garnock-Jones | Mob: +44 (0)7905 974 211
 LShift Ltd | Tel: +44 (0)20 7729 7060
  http://www.lshift.net/ | Email: tonyg at lshift.net
More information about the rabbitmq-discuss