Erlang管理员重新启动连接到Downed主机的策略 [英] Erlang Supervisor Strategy For Restarting Connections to Downed Hosts

问题描述

我正在使用erlang作为服务之间的桥梁，我想知道人们为处理连接失败而提出了什么建议？

我正在从本地文件和将其管理到AMQP，可以想象AMQP经纪人可能会下降。对于这种情况，我想继续重试连接到AMQP服务器，但是我不想用这些连接尝试来连接CPU。我的倾向是将睡眠重新启动AMQP代码。这不是黑客本质上规避了快速失败的目的，并且让erlang处理它吗？更一般地说，应该使用erlang主管行为来处理连接失败？

解决方案

我认为编写自己的语义是合理的自己处理与外部服务器的连接。监督者最适合处理您自己的进程树中的崩溃/锁定/否则不健康的进程，而不是重新连接到外部服务。

您的进程是否管理本地文件与AMQP经纪人相同的流程树，还是单独的服务？

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?

解决方案

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?

这篇关于Erlang管理员重新启动连接到Downed主机的策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！