[erlang-questions] Question about Distributed Applications

[Ulf Wiger]

No, you're right. That would avoid the unnecessary
takeover, since the two nodes are configured as equals.

BR,
Ulf W

2008/12/17 Chris Goffinet <cg@REDACTED>:
> Hi Ulf:
>
> I was messing around with the distributed config last night:
>
> Sample config from documentation page:
>
> [{kernel,
>   [{distributed, [{myapp, 5000, [cp1@REDACTED, {cp2@REDACTED}]}]},
>    {sync_nodes_mandatory, [cp2@REDACTED]},
>    {sync_nodes_timeout, 5000}
>   ]
>  }
> ].
>
>
> I changed the sample config to this:
>
> [{kernel,
>   [{distributed, [{myapp, 5000, [{cp1@REDACTED, cp2@REDACTED}]}]},
>    {sync_nodes_mandatory, [cp2@REDACTED]},
>    {sync_nodes_timeout, 5000}
>   ]
>  }
> ].
>
> It did exactly what I was looking for. Did I find a fluke?
>
>
> On Dec 17, 2008, at 1:29 AM, Ulf Wiger (TN/EAB) wrote:
>
>> Chris Goffinet skrev:
>>> Hi
>>> I was reading over:
>>> http://www.erlang.org/doc/design_principles/distributed_applications.html
>>> And saw that if you had 3 nodes (A,B,C), and A failed, B would
>>> take  over. If A came back, B would eventually shutdown and A would
>>> take  over. Is it possible at all to disable the takeover? So if A
>>> comes  back, as long as B is still running, nothing changes?
>>
>> It is possible, but not exactly easy. (:
>>
>> You can use application:permit(App, false) on A to tell the
>> application
>> controller that you don't want it to start App there. Of course, you'd
>> have to do this early on, and you'd likely end up writing your own
>> simple cluster controller of sorts. One way to do this would be to
>> store a configuration in a mnesia table, and then start a process
>> early that checks the configuration and calls permit() accordingly.
>> It sounds simple enough, but the devil's in the details, as usual.
>>
>> Another way to go about it is to in fact write your own distributed
>> application controller. To know how to do this, you pretty much
>> need to read the comments in application_controller.erl
>> One key function is application_controller:control_application(App).
>> This can only be called once per app (there is no un_control()),
>> so you need to make sure that the dist_ac is not used at the same
>> time.
>>
>> A /very/ good idea is to spawn a process per app that becomes the
>> controlling process, and then send that process simple commands
>> like run/dont_run. The message passing interface to the OTP
>> application controller is described in the comments.
>>
>> This second alternative is of course /very/ advanced. I'd personally
>> recommend using gen_leader for a cluster controller (that was partly
>> the original purpose for gen_leader). In fact, I and a few others are
>> slowly working on such a cluster controller component. Don't hold your
>> breath, though.
>>
>> BR,
>> Ulf W
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>