补偿 one_for_one 主管无法重新启动子进程：tcp/ip 端口侦听器
我创建了一个封装 tcp/ip 功能的通用行为。该行为的所有用户所要做的就是实现处理来自套接字另一端的任何内容的已解析“命令”的回调。
我的通用行为创建了一个端口侦听器进程，该进程通过 gen_tcp:accept 侦听端口。当有人连接到端口时，端口侦听器会要求主管启动一个新的端口侦听器，同时继续处理与刚刚连接的任何客户端的套接字通信。因为每个端口侦听器/套接字处理程序都是动态创建的并且相同，所以我使用 simple_one_for_one 管理程序来创建它们。标准的东西。
这是我的问题。如果端口侦听进程终止，则整个行为将不起作用，因为将没有任何内容侦听端口。由于端口侦听器是由 simple_one_for_one 管理程序创建的，因此管理程序无法重新启动新的 port_listener。
那么，我是否创建一个 keep_alive 进程来监视“最新”端口侦听器，并要求主管启动另一个进程（如果该进程死亡）？或者，对于此类案例是否还有其他最佳实践。
另外，有没有办法查看/检查此行为所创建的进程？它不是一个应用程序，所以 appmon 在这里不起作用。
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能只能继续使用一个侦听器进程，因为您始终能够通过以下方式将套接字所有权传输给另一个进程
，然后您的侦听器也将能够。
那么你就不会被迫simple_one_for_one担任最高级别的主管，而是one_for_one。或者你认为应该更适合的。然后，顶级主管将使用 simple_one_for_one 策略生成侦听器进程和接受器主管。那么如果出于某种原因（并且如果您愿意）发生故障，侦听器肯定会重新启动。
此外，您可以参考 cowboy 项目来了解作者使用的方法。
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
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.