Question

I have created a generic behavior that encapsulates tcp/ip functionality. All the user of the behaviour has to do is implement the callbacks that handle parsed “commands” that come from whatever is on the other side of the socket.

My generic behvour creates a port-listener process that listens on a port via gen_tcp:accept. When someone connects to the port, the port-listener asks a supervisor to spin-up a new port-listener while it goes on to handle the socket communication with whatever client just connected. Because each of these port-listeners / socket-handlers are dynamically created and identical, I am using a simple_one_for_one supervisor to create them. Standard stuff.

Here is my question. If the port-listening process dies, the entire behivour is non-functional since there will be nothing listening to the port. Becuase the port-listener is create by a simple_one_for_one supervisor, the supervisor cannot restart a new port_listener.

So, do I create a keep_alive process that monitors the “latest” port listener and asks the superviosr to start another one should it die? Or, is there some other best-practice for this type of case.

Also, is there a way to see/examine the process being created by this behavior? It is not an application, so appmon doesn’t work here.

Thanks

Answer 1

You probably could go on with only one listener process since you are always able to transmit the socket ownership to another process by means of

gen_tcp:controlling_process(Socket, Pid)

And then your listener will be able too.

Then you would not be forced to simple_one_for_one supervisor at the top level but one_for_one instead. Or what you think should fit better. The top level supervisor will then spawn listener process and acceptors supervisor with simple_one_for_one strategy. Then the listener will surely be restarted if goes down somewhy (and if you want to).

Further you may consult a cowboy project to see what approaches authors are using.