[erlang-questions] how: distributed supervision tree

[Zvi]

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.

[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 <ex...@walla.com>:

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>

[Zvi]

Ulf,

So what you suggesting, is to use "forest" of the single-node supervision
"trees".
Then the "forester" or "woodward" will monitor, and start/restart/shut the
top-level supervisor in each "tree". Such a "forester" can't use Erlang's
built-in trap-exit/process linking mechanism and should reimplement
distributed version of it.

Thanks,
Zvi

--
View this message in context: http://www.nabble.com/how%3A-distributed-supervision-tree-tf4872110.html#a13983949

[Ulf Wiger (TN/EAB)]

Zvi skrev:

> Ulf,
>
> So what you suggesting, is to use "forest" of the single-node supervision
> "trees".
> Then the "forester" or "woodward" will monitor, and start/restart/shut the
> top-level supervisor in each "tree". Such a "forester" can't use Erlang's
> built-in trap-exit/process linking mechanism and should reimplement
> distributed version of it.
>
> Thanks,
> Zvi

A supervision tree is usually encapsulated within an application.
Through OTP's release handling framework, you can build a boot script
that loads all the code(*) and starts the applications you need.

You can specify where each application should run in a distributed
system. It is most common to run the same boot script on each node,
and then configure the kernel application to start the right
applications. If the system is supposed to recover automatically,
you should make sure that the erlang node is supervised and
restarted, if it dies. This can be done in different ways.

You specify distribution logic e.g. in a sys.config file, which is
identified with the -sys parameter when starting erlang.

An example sys.config:

[{kernel,
[{distributed,
[{a, [node@hosta, node@hostb]}]
}]
}]

This would tell the distributed application controller to start the
application 'a' on node@hosta, if available, otherwise on node@hostb.
If the node running the application dies, the controller will move it
to an alternative node.

You can read more about it on the man pages for 'kernel' and
'application' (and 'erl', if you want to read more about command-
line arguments).

BR,
Ulf W