Erlang Supervisor Strategy For Restarting Connections to Downed Hosts

Question

I'm using erlang as a bridge between services and I was wondering what advice people had for handling downed connections?

I'm taking input from local files and piping them out to AMQP and it's conceivable that the AMQP broker could go down. For that case I would want to keep retrying to connect to the AMQP server but I don't want to peg the CPU with those connections attempts. My inclination is to put a sleep into the reboot of the AMQP code. Wouldn't that 'hack' essentially circumvent the purpose of failing quickly and letting erlang handle it? More generally, should the erlang supervisor behavior be used for handling downed connections?

Ostend

Answer 1

I think it's reasonable to code your own semantics for handling connections to an external server yourself. Supervisors are best suited to handling crashed/locked/otherwise unhealthy processes in your own process tree not reconnections to an external service.

Is your process that pipes the local files in the same process tree as the AMQP broker or is it a separate service?

Reticulation

I agree. Maybe supervisors shouldn't play into the business logic, they're just there to handle dead processes and keep things consistent (one_for_all, one_for_one, etc). And yes, the file piper and the AMQP client process are seperate processes. The erlang-amqp-client creates a process for every connection (or is that channel?), now I just need to handle it dying. Lots to learn! – Ostend