<div dir="ltr">T Ty, Sean Cribbs thinks Riak and Disruptor have very little in common: <a href="http://riak-users.197444.n3.nabble.com/Disruptor-like-behaviour-td4032394.html">http://riak-users.197444.n3.nabble.com/Disruptor-like-behaviour-td4032394.html</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 14, 2015 at 9:04 AM, xu xiut <span dir="ltr"><<a href="mailto:xiut.xu@gmail.com" target="_blank">xiut.xu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="https://github.com/LMAX-Exchange/disruptor/wiki/Introduction" target="_blank">https://github.com/LMAX-Exchange/disruptor/wiki/Introduction</a><br><div><br></div><div>Does the disruptor still sound like Riak?</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Jan 13, 2015 at 10:36 AM, T Ty <span dir="ltr"><<a href="mailto:tty.erlang@gmail.com" target="_blank">tty.erlang@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Your comment is quite interesting. My take-away from reading the LMAX article wasn't the single threaded business logic process nor the shared memory communication.<div><br></div><div>My take-aways were: </div><div><br></div><div>1. pipelining. Do all input validation and transformation before/after main business logic processing. This makes coding the 'happy-path' easier and keeps the business logic core small.</div><div><br></div><div>2. the business logic process is a master process that reacts to events and generate events. This allows scaling of the business logic process as it makes it easier to spawn processes to deal with the events. (gen_event/gen_fsm triggering supervisor in simple_one_for_one that starts other processes)</div><div><br></div><div>3. Event Sourcing. One added benefit is compliance. It is easier to demonstrate compliance when there are events to show how the system changed from one state to another. Compliance here can mean security compliance or regulatory compliance. </div><div><br></div><div><div>4. business logic processor deals with events in-memory. mnesia ram_tables fit this criteria easily as do ets tables. </div></div><div><br></div><div>5. Business Logic State Snapshot. Not only does this allow resilience between node restarts it also allows migrating the partial process to a different node entirely. </div><div><br></div><div>6. Avoiding external service calls in the Business Logic process. Transition to an event based model for interacting with external services. Have a middle layer of gen_fsm to determine where in the logic the current process is in.</div><div><br></div><div>7. Mention about session data being transient and can be discarded. Aka let process die and supervisor restart.</div><div><br></div><div>The Disruptor sounds like Riak.</div><div><br></div><div>Cheers</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 2:11 PM, Mihai Balea <span dir="ltr"><<a href="mailto:mihai@hates.ms" target="_blank">mihai@hates.ms</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Jan 12, 2015, at 4:10 AM, T Ty <<a href="mailto:tty.erlang@gmail.com" target="_blank">tty.erlang@gmail.com</a>> wrote:<br>
><br>
> The LMAX architecture is an easy fit for Erlang and one which an Erlanger would naturally arrive to.<br>
<br>
</span>I beg to differ. LMAX uses a single threaded process to implement its entire business logic, which makes it highly sensitive to sequential performance. This is not one of Erlang’s strong points. Also, the disruptors - which are essentially fancy circular buffers - depend on preallocated memory and destructive updates to attain their performance. Finally, the communication between various stages in the pipeline is done through shared memory, and they do some clever tricks to avoid locking.<br>
<br>
Yes, you could emulate this architecture in Erlang, but you won’t get anywhere near LMAX’s performance.<br>
<span><font color="#888888"><br>
Mihai<br>
<br>
</font></span></blockquote></div><br></div>
</div></div><br></div></div><span class="">_______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>