[erlang-questions] Question about Distributed Applications

[Chris Goffinet]

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