[rabbitmq-discuss] Rabbit Client Supervision Architecture

[Matthew Sackman]

Hi Erik,

On Wed, Sep 22, 2010 at 11:49:49AM +0000, Erik Seres wrote:
> I think I have one question regarding connections. So, you explain that an 
> exclusive queue must be deleted when a connection closes. On that same note, 
> however, how do you locate a durable queue after a connection had died (or had 
> been closed) and then you reopened it? If one can locate a durable queue after a 
> disconnect/connect, which my understanding is one must be able to, then why can 
> one not locate an exclusive queue the same way? (Tell me if I just need to dive 
> in the AMQP specs to understand this.)

The details (but not content) of all queues are stored in mnesia, in
Rabbit. This means that when Rabbit restarts, we can check to find which
queues were durable and get them to be recreated. Non-durable queues
that we find on startup get nuked. Queues with exclusive owners record
the Pid of their owner. Thus at queue creation time (regardless of
whether it's rabbit startup or normal queue creation), we have the queue
monitor the pid of its owner. When the queue gets the DOWN message
(which may be immediately if the queue's being restarted), the queue
self-destructs.

The problem with restarting the connection then is that there is no way
to identify that the new connection is replacing the old: the Pid of the
connection will have changed, and you can't do it by user authentication
as there's nothing to stop the same username/password being used by many
connections concurrently. There is no session-id concept in AMQP which
is what prevents this sort of thing from being achievable.

> In my application at startup, I will open a connection and then, each 
> application process wanting to communicate over AMQP, will open a channel. The 
> application will need to know if the amqp_client has crashed and the connection 
> and channels have been lost. So, I thought I would add the process ID returned 
> by amqp_connection:start(network, ...) to my supervision tree. This does not 
> seem to work, though, as the connection PID never shows up under my application 
> supervisor as a child. And, consequently, it never gets restarted in case of a 
> crash. I have the "Type" in the ChildSpec set to 'supervisor' for this child. 
> With that said, how should I go about detecting when/if the amqp client has 
> crashed?

Just link directly to either the Pid of the connection or the Pid of the
channel. If either go down abnormally, it'll take out your process (and
vice versa - in fact, you may want to just monitor rather than link).

Also, the Pid you get back from amqp_connection:start/1 is _not_ the Pid of the
supervisor. It's the Pid of the amqp_{network,direct}_connection
process. The Pid of the connection_sup is never returned. Fairly soon,
the entire client will become a real application and then it will be
properly visible in things like appmon.

> Also, what do you think is the expected time frame before this client library 
> becomes officially supported?

Err, the really really pessimistic view is 3 months. So hopefully before
then.

Matthew