[erlang-questions] how: distributed supervision tree

[Ulf Wiger]

I would guess that what you're attempting to do is rather unusual.
While the supervisor behaviour doesn't stop you from spawning
a remote process, and it's quite possible to monitor a remote pid.

The problems occur, as you note, when the process is to be
restarted. It's not certain that the supervisor can do what it takes
to start the process (e.g. if the remote node is down), and the
supervisor is not designed to take these problems into account.

It is more commonplace to use the distributed application controller
for redundancy logic, keeping the supervision trees together on each
node.

BR,
Ulf W


2007/11/26, Zvi <exta7@REDACTED>:
>
> The supervision strategy data structure is a list of tuples for each worker.
> The Worker specifications are tuples of the following form:
>
> {Tag, {Mod, Func, ArgList},
>          Restart,
>          Shutdown,
>          Type,
>         [Mod1]}
>
> Where:
>     {Mod, Func, ArgList}
> defines the function that the supervisor will use to start the worker. It is
> used as arguments to apply(Mod, Fun, ArgList).
>
> How do I define worker process, which should be started/restarted on remote
> node?
> Should I just write Mod:Fun function which calls spawn/2 ,i.e.
> spawn(Node,Fun) ?
> What happens if BEAM VM on node "Node" is down? Should Mod:Fun first call to
> some shell script to lanch VM on the remote node and only then spawn
> Worker's Erlang proces on it?
>
> Anybody has example?
>
> Thanks in Advance
> Zvi
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/how%3A-distributed-supervision-tree-tf4872110.html#a13941497
> Sent from the Erlang Questions mailing list archive at Nabble.com.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>