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....) 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.
> 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....)
> 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.
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.
> > 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....)
> > 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.
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.
On Wednesday, June 6, 2012 12:50:15 AM UTC+2, Bikram wrote:
> 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
> On Wed, Jun 6, 2012 at 12:43 AM, André Graf <andre.g...@erl.io> wrote:
>> 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é
>> On 6 June 2012 00:30, Bikram <razorp...@gmail.com> wrote:
>> > Hi,
>> > In continuation to my comment on cross node process management. Given >> below
>> > are couple of links that I found useful:
>> > 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.... >> )
>> > 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.
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.
On Wed, Jun 6, 2012 at 2:07 PM, Agustin Cautin <acau...@gmail.com> wrote:
> 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.
> On Wednesday, June 6, 2012 12:50:15 AM UTC+2, Bikram wrote:
>> 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
>> On Wed, Jun 6, 2012 at 12:43 AM, André Graf <andre.g...@erl.io> wrote:
>>> 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é
>>> On 6 June 2012 00:30, Bikram <razorp...@gmail.com> wrote:
>>> > Hi,
>>> > In continuation to my comment on cross node process management. Given
>>> below
>>> > are couple of links that I found useful:
>>> > 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).
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.
On Wednesday, June 6, 2012 3:13:04 PM UTC+2, Bikram wrote:
> 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
> On Wed, Jun 6, 2012 at 2:07 PM, Agustin Cautin <acau...@gmail.com> wrote:
>> 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.
>> On Wednesday, June 6, 2012 12:50:15 AM UTC+2, Bikram wrote:
>>> 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
>>> On Wed, Jun 6, 2012 at 12:43 AM, André Graf <andre.g...@erl.io> wrote:
>>>> 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é
>>>> On 6 June 2012 00:30, Bikram <razorp...@gmail.com> wrote:
>>>> > Hi,
>>>> > In continuation to my comment on cross node process management. Given >>>> below
>>>> > are couple of links that I found useful:
>>>> > 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).
> 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.
> On Wednesday, June 6, 2012 3:13:04 PM UTC+2, Bikram wrote:
>> 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
>> On Wed, Jun 6, 2012 at 2:07 PM, Agustin Cautin <acau...@gmail.com> wrote:
>>> 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.
>>> On Wednesday, June 6, 2012 12:50:15 AM UTC+2, Bikram wrote:
>>>> 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
>>>> On Wed, Jun 6, 2012 at 12:43 AM, André Graf <andre.g...@erl.io> wrote:
>>>>> 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é
>>>>> On 6 June 2012 00:30, Bikram <razorp...@gmail.com> wrote:
>>>>> > Hi,
>>>>> > In continuation to my comment on cross node process management.
>>>>> Given below
>>>>> > are couple of links that I found useful:
>>>>> > 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).
