[erlang-questions] Fishing for best practices: distributed twin processes!

[Michael Truog]

Assuming you have the 2 layers in separate Erlang VMs.  You can have the Erlang VMs connected with distributed Erlang, and have the twin processes monitoring each other.  If you wanted a simple process death if either died, you could consider using a link instead of 2 monitors.  However, that seems like the simplest solution, to avoid unnecessary complexity.  You might find strangeness if you start not using the default net tick time (i.e., with a process link inbetween nodes), with distributed Erlang, but you probably know it is best to not play with that.

On 09/14/2012 03:27 PM, Roberto Ostinelli wrote:
> Dear list,
>
> I have a 2-layer architecture where:
>
>     * the first layer is handling the socket connections to the outside world clients
>     * the second layer is performing computations related to the connected clients (i.e. the core application)
>
> It is built in this way so that we can make the socket handlers very stupid. Therefore, crashes on the first layer are less likely to occur, and in case of crashes of the second layer (the core application) we don't have all the clients trying to reconnect at the same time: they'll still be connected (even though receiving a 'service unavailable' message of some kind).
>
> For every single process handling a socket connection on the first layer I therefore need to have a 'twin' process on the second layer, strictly connected to its socket manager counterpart.
>
> I'm fishing for best practices here:
>
>     * how can I assure that if the second layer goes down (VM crash, server hit by an angry sysadmin), the first layer socket processes know that their twin process is down (and the other way around)?
>     * what is the best way to handle the creation of the twin processes?
>
> Any input welcome. ^^_
>
> r.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120914/50d6c0db/attachment.htm>