[rabbitmq-discuss] Linking to a channel process (erlang client)

Hmm, that's tricky. Depends what you want to do really - you could have
the supervisor link to the base process that is the amqp_client
application if you want (before starting any workers), but it depends if
you want death of your application to tear down the whole client -
sequencing of those actions to achieve a safe, controlled shutdown, is
not trivial.

My understanding is that on the whole, libraries that spawn processes
are linked to, or monitored, rather than linking / monitoring their
clients. However, this may be wrong and/or not best practise. If you
have ideas how this can be improved, please do let us know.

Best wishes,

Matthew

Currently, my application's top-level supervisor starts amqp_sup as a
child itself which gives the behaviour I want when my application
crashes. That works quite well and behaves as I expect.
My main concern is leaking processes since client-side channels are
composed of at least 3 processes each (and I expect hundreds of
channels in this particular application).

I've seen other "client" applications which manage socket connections
treat this issue very differently. For example, lhttpc
(https://github.com/esl/lhttpc) spawn_links a simple lhttpc_client
process, passing along self() in order to unlink when a request is
finished. Obviously, HTTP clients are largely stateless which differs
greatly from the situation we have with AMQP connections and channels.

Based on a suggestion, I will most likely trap exits in the worker
process while setting up the link to the channel in order to clean up
if it receives an exit signal from elsewhere. Because the worker
processes are quite simple, this should be fine.

Thanks for your help,
Hunter

Interesting, and thanks for the pointer. I'll take a look at that and we
may well change the behaviour here, or at least introduce a start_link
variant as there used to be.

Matthew