Erlang processes in node pool

[Bikram]

Hi,

In continuation to my comment on cross node process management. Given below are couple of links that I found useful:

http://www.erlang.org/doc/man/pool.html#start-1 

http://www.erlang.org/doc/man/slave.html#start_link-1

http://www.erlang.org/doc/design_principles/distributed_applications.html 

It seems I was mistaken in assuming that state is transferred automatically, which apparently is not the case. But maintaining a list of nodes and by sending a message to a supervisor/gen_server on next node in a list in state on process terminate; the transfer of state can probably be achieved (in theory).

However application redundancy at cluster level can also be achieved (http://www.erlang.org/doc/design_principles/distributed_applications.html) to the same effect. But state preservation (or a pseudo effect of that) would depend on the design of the application (e.g. having a replicated in-memory mnesia cluster for storing the state).

All these being my wild ideas, would be good to hear views on this.

Best,

Bikram

[André Graf]

Hey Bikram

Can you please elaborate more on the topic, so that the poor guys not
being able to attend the today meeting can follow the discussion.

Cheers and Thanks!
André

[Bikram Chatterjee]

Hi André,

Sorry, my bad!

We were discussing that in a erlang cluster scenario, is it possible to define fallback nodes for a process so that if it crashes on one node it will be automatically started in another with the current state pre-loaded. 

This is my understanding of the problem statement others please correct me if I am wrong.

And how is Berlin treating you this time?

Cheers!

Bikram

[Agustin Cautin]

Hello Everyone,

Yes this is exactly the problem, maintaining the state of a process on a remote note in case that the local node dies for whatever reason. Now this can't be achieved sending a message on process termination due to the fact that the note might be already disconnected by the time the termination takes place.

Mnesia seems to be the best/simplest alternative so far.

Regards

Agustin.

[Bikram Chatterjee]

Hi Augstin,

When I proposed Mnesia, I didn't considered the node's death (I only considered processe's death). But as you have pointed out. A node's death is quite tricky.

First of, is there was any last minutes sync mnesia cluster needed before the node died will be lost anyway. Besides, there must be a master process running somewhere which monitors every appserver node and triggers a process spawn if a node is dead. If I understand (and remember) correctly you arch had an identical set of app servers. So the question will still remain where would you run this node monitoring service?

This started to look quite challenging task (and somewhat unexplored) compared to JBoss and other app clusters.

It would be great to learn more on this from the Erlang exparts in the list.

Cheers!

Bikram

[Agustin Cautin]

Hello Again,

Since I just implemented an application spawning a backup on a different node, the is the code is here https://github.com/acautin/distributed-state-example

Seems to work fine, at least in one machine, but since erlang is network transparent it should work exactly the same in several machines :p.

Regarding Mnesia I think that it support transactions so you always can wait for remote commit to come back before returning the modified state and the answer to the user. Next weekend maybe I will try to implement the same state keeper using mnesia.

Regards.

Agustin.

[Bikram Chatterjee]

Sounds interesting.

Please let us know how it goes.

Bikram