<div>75 machines in a fully connected distributed erlang network is a bit much but it should work.</div><div>use case 1: Why do you need to store to mnesia and all machines read from it? If you have 75 servers erlang connected, you can just send a simple erlang message to all of them.</div>
<div>use case 2: In a fully connected erlang network you always know which machines are offline/online. Every machine has a name.  If you simply sort all online machines by node name, that is the node you pick to do authentication. No real synchronization required and it will work even if that machine is lost. Or you can hardcode a sequence of machines which ones do the authenticating. First in list that is online is the one that does it.</div>
<div><br></div><div><br></div>Sergej<div><br><div class="gmail_quote">On Fri, May 18, 2012 at 11:00 AM, Ovid <span dir="ltr"><<a href="mailto:curtis_ovid_poe@yahoo.com" target="_blank">curtis_ovid_poe@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Courier New,courier,monaco,monospace,sans-serif"><div><span>Hi there,</span></div>
<div><span><br></span></div><div><span>We've a system that run across 75 servers and needs to be highly performant, fault-tolerant, scalable and shares persistent data across all 75 servers. We're investigating Erlang/Mnesia (which we don't know) because it sounds tailor-made for our situation.</span></div>
<div><span><br></span></div><div><span>We are not using Erlang for our first implementation, but are instead hacking together a solution from known technologies including Perl, MySQL and Redis. We're considering Erlang for our future work.</span></div>
<div><span><br></span></div><div><span>We have two primary needs: Each box can bid on an auction and potentially spend a tiny amount of money and each of the 75 boxes will receive notifications of a small amount of money spent if they
 win the auction (the auction notification will probably not be sent to the box bidding in the auction).</span></div><div><span><br></span></div><div><span>Use case 1: If the *total* of all of those small amounts exceeds a daily cap or an all-time cap, all 75 boxes must immediately stop spending bidding in auctions. It seems that each box can run a separate Erlang process and write out "winning bid" information to an Mnesia database and all boxes can read the total amount spent from that to determine if it should stop bidding.</span></div>
<div><span><br></span></div><div><span>This seems trivial to set up.</span></div><div><span><br></span></div><div><span>Use case 2: we periodically need to reauthenticate to the auction system. We MUST NOT have all 75 boxes trying to reauthenticate at the same time because we will be locked out of the system if we do this. Having a central box handling reauthentication is a single point of failure that we would like to
 avoid, but we don't know what design pattern Erlang would use to ensure that only one of the 75 Erlang instances would attempt to reauthenticate at any one time (all 75 boxes can share the same authentication token).</span></div>
<div><span><br></span></div><div>Use case 1 is clearly perfect for Erlang. Use case 2 is less clear to us. We're going to be spending a fair amount of time hacking together a non-Erlang solution, but the benefit is using known technologies that don't depend on the "one guy who knows the system".</div>
<div><br></div><div>At full scale, we anticipate billions of auctions per day.</div><div> </div><div>Does anyone care to comment about things we should look at? Particularly, is use case 2 not something appropriate for Erlang? A tiny amount of sample code would be lovely (note: I am somewhat comforable with Prolog, so Erlang looks fairly straightforward for me, aside from understanding the message
 passing).</div><div><br></div><div>Cheers,</div><div>Ovid</div><div>--<br>Live and work overseas - <a href="http://www.overseas-exile.com/" target="_blank">http://www.overseas-exile.com/</a><br>Buy the book           - <a href="http://www.oreilly.com/catalog/perlhks/" target="_blank">http://www.oreilly.com/catalog/perlhks/</a><br>
Tech blog              - <a href="http://blogs.perl.org/users/ovid/" target="_blank">http://blogs.perl.org/users/ovid/</a><br>Twitter                - <a href="http://twitter.com/OvidPerl/" target="_blank">http://twitter.com/OvidPerl/</a></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>