Erlang Supervisor Strategy For Restarting Connections to Downed Hosts

views:

answers:

+5 Q:

Erlang Supervisor Strategy For Restarting Connections to Downed Hosts

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?

+2 A:

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?

Jeremy Wall 2010-06-06 04:48:09

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!

derdewey 2010-06-07 16:59:49

ansaurus

tags:

views:

answers:

Erlang Supervisor Strategy For Restarting Connections to Downed Hosts

related questions