<div dir="ltr">Let me try to give you a simple example to illustrate the use of distributed applications. Let's say you have a website and you want it to serve with a cluster of N nodes. You need a web server application, and that should be really running on all the nodes (so it's not an OTP distributed application), so all of the nodes will be utilised. But you also have an application that sends out a daily newsletter of top articles or whatever to your users. It is not a good idea to start this application on all the N nodes independently, because each of them would independently send out the same email, so your users would get N copies of that. Sending the newsletter is a task that should be done on exactly one node in the cluster (but it doesn't matter on which one): this is the use case for distributed applications. It's not about distributing load across nodes, it is for electing a single node in a distributed system to perform some task that has to be performed only once.<div><br></div><div>But to be honest I wouldn't really recommend using distributed applications. They are very rarely used, and their implementation is not very robust. Practically, never try to have more than one distributed application in your release. (For those interested in the technical details: the dist_ac processes across the cluster run a protocol to decide where to start a distributed application. They can only run the protocol for one application at a time, and all the nodes have to participate in the protocol, so until a decision is made, they cannot handle requests to start an other application. Now let's imagine you have two distributed applications in your release, A and B (started in this order). If the node running B crashes and gets restarted by heart, the dist_ac processes may deadlock, because the newly restarted node would start running the protocol for A first, while the rest of the cluster is still running the protocol for B which has to be restarted somewhere after the crash.) There are better solutions for selecting a single node (or process) for doing a task only once in a cluster, such as gproc or global registered names.</div><div><br></div><div>Cheers,</div><div>Daniel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Aug 2019 at 17:38, I Gusti Ngurah Oka Prinarjaya <<a href="mailto:okaprinarjaya@gmail.com">okaprinarjaya@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Again, my questions and confusions will base on Learn-You-Some-Erlang book. Yes, because i learn erlang from that book. And..thank you so much, Fred.</div><div><br></div><div>Now, i just finished read and practicing <a href="https://learnyousomeerlang.com/distributed-otp-applications" target="_blank">https://learnyousomeerlang.com/distributed-otp-applications</a> part of the book. From this part, i learn how to develop a super simple distributed app that runs in 3 separated nodes. </div><div><br></div><div>I have web service infrastructure experience. I've done several freelance projects related to improving availability and delivery speed. Mostly done by clustering web servers, database servers, distributing traffic to clustered web servers, routing write and read to clustered databases servers, etc. My tools such as NginX, MariaDB Galera, MariaDB MaxScale, HAProxy, etc.</div><div><br></div><div>If i try to compare what i learn in <a href="https://learnyousomeerlang.com/distributed-otp-applications" target="_blank">https://learnyousomeerlang.com/distributed-otp-applications</a> with my experiences, i can't see the benefits of distributed erlang/otp app that explained in the book. Then my questions are:<br><br>1. Based on the book, i can't see the benefits by creating 2 backup nodes. Because there's no traffic distribution. Having 3 web-server machines then distributing traffic to them is more make sense for me for now. If 1 web-server failure, there's still 2 web-server left to serve.</div><div><br></div><div>2. Based on the book, service/module can execute at any nodes, but the service originally at the main / 1st node as long as the 1st node still alive. Service executed at 1st node. I can't see the benefits. Because in the end, it will only burden the 1st node. So what is the other 2 backup node is for? only act as a forwarder? The other 2 backup nodes are just "sitting", passive, doing nothing (except forwarding request) waiting for the 1st node to die.</div><div><br></div><div>3. I do really need to understand Erlang distributed programming, is there any more practical <b>simple</b> example? Yes, simple example, because if you ask me to read RabbitMQ's source code, that will make me drunk hahaha 😅</div><div><br></div><div>Please enlightenment</div><div><br></div><div>Thank you</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>