Hi Tino, Readers: WARNING, going off on a "technical"/philosophical tangent below.
(Patrik has already answered most of it from a practical perspective.) On Sat, Feb 1, 2014 at 3:24 AM, Tino Adams <[email protected]> wrote: > Hi Vic > > > > On Saturday, February 1, 2014 10:09:52 AM UTC+11, √ wrote: > >> Hi Tino, >> >> >> >> On Fri, Jan 31, 2014 at 11:16 PM, Tino Adams <[email protected]> wrote: >> >>> Thanks for the replies everyone. >>> >>> I'm still waiting for the Heureka moment in my brain to kick in when it >>> comes to modelling actor systems. >>> My confusion is around the basic guarantees especially when it comes to >>> Akka's primitives like "watch" and "setReceiveTimeout" for instance. >>> >> >> Is this a question? If so what is it. >> > >> > >> >>> >>> Is it guaranteed, even for distributed actors, that messages send by >>> actor A to actor B will at least end up in the mailbox of Actor B? >>> >> >> No. What if the network is down or the Actor is dead? >> > >> >>> Or are there simply no guarantees at all and actors may never get to see >>> even "Terminated" or "Timeout" messages? >>> >> >> What guarantees does your JVM give you that any Threads will ever get to >> run? >> > > I'm not familiar with the guarantees of the dynamic dispatch in the JVM > but pretty confident that a method call either fails or the target function > is invoked since the call is completely synchronous. > You're assuming that the OS Scheduler ever schedules that thread. What if it is perpetually starved? > So calling start() would at least guarantee me that the Thread has been > registered for scheduling. I guess in my head running a thread != > communicating with it. If I am now interested in the outcome of the > computation then I "just" need to figure out a way to communicate > reliably (including timeouts in case the Thread is never scheduled). That > could be done in the business logic a la > http://www.infoq.com/articles/no-reliable-messaging. > Absolutely, this is why I objected to the term "guarantee" as everyone has a different definition and what it would implicate. Instead of talking about guarantees, I'd propose to talk about reliability—the degree of reliability and under which circumstances. > > >> >> >>> Or are there different guarantees for Akka primitives? >>> >> >> How do you mean? >> > > Can I rely on the fact that my Actors receive method will get to handle > "Terminated" or "ReceiveTimeout" messages sent from the ActorSystem? > Yes—I'd say that you can definitely rely on it. But does that mean that nothing else could ever happen? (Again: That really depends on what degree of reliability one assumes, and under which circumstances.) Let's say that the Actor is stopped before it gets to process the message, or the mailbox implementation that you have decided to use drops messages? What if power is lost? What if memory has been corrupted? What if your JVM is bugged? What if all storage is lost? What if an asteroid hits earth? > And if that is true how does the ActorSystem manage to give me that > guarantee for those messages but not for Actor to Actor messages? > System messages (think of them as "signals") have a higher degree of fidelity/reliability. And we reliably detect if we cannot send them, so we can decide to have to assume that the remote location is dead. > If I can't even rely on "system" messages being received by the Actor then > I'm at a total loss here. > You can definitely rely on it. This doesn't mean that there aren't possible, but extremely unlikely, scenarios where your assumption can be violated. This is just a fact of life. > > >> >> >>> >>> In the Akka persistence package for instance, the Channel actor offers >>> at-least-once semantics by retrying messages until an ack is received. >>> However, as the sender (A) I'm sending the intended message to Channel (C) >>> which again means I have no guarantee that it ever ends up in the Channel >>> as there are no guarantees between A and C. Something must be wrong >>> with my understanding and or expectations... >>> >> >> I think the real question here is "What does guarantee mean and under >> which circumstances does it apply?" >> > > If the term at-least-once guarantee is ambiguous and perhaps doesn't apply > in certain circumstances then that would be a fantastic starting point for > a discussion about reliability. > Oh, there are many such situations. Let's just start with: permanent delivery failure. Or even better: lost or corrupted storage of the messages to be resent. > I'm not negotiating ACID guarantees with my DB depending on the > circumstances, I rely on it come rain or shine. > ACID is just not a blanket definition—there are _many_ different degrees of isolation. Not to mention that storage can be corrupted or lost. Does that mean that ACID is unreliable? I'd say that it works very well without having to think too much about things, but it depends on what you expect! > In Erlang and I quote: Message sending is asynchronous and safe, the > message is guaranteed to eventually reach the recipient, provided that the > recipient exists. ( > http://www.erlang.org/doc/reference_manual/processes.html) > But that is provably not true. Between different Erlang Nodes, if the network is perpetually severed there just simply is no way to deliver the message. Even on a non-distributed Erlang system consider the following situation: Process A Process B Process B has a selective receives that will never match anything it gets sent (or think of it as there are more messages it cannot receive that are coming in compared to the ones it can) so at some point its mailbox will be full (no harddrives have infinite storage AFAIK) and therefor the A cannot send to B, because B has no place to put it. > With that I can trust that for instance system messages like "Terminated" > will definitely be received and if the recipient doesn't exists my Actor > would have guaranteed been informed about it. > Again, this is completely depending on what we mean when we say "guarantee" and "definitely". For instance: Will we _definitely_ see tomorrow's sunrise? If so, can someone _guarantee_ it? > > I'm super excited about having the opportunity to get some input from you > Vic as I've been pondering over that stuff for quiet a while now. > I naively went head first last year and now have two reasonably sized Akka > projects in production :) > That sounds fantastic, a happy hAkker I hope? > > I will go through some of the examples again. I remember thinking that > most examples correct working relies on receiving at least the "Terminated" > messages when child Actors have gone away. Same applies to Supervision > strategies, are those based on message exchange and if so how did you > manage to guarantee that your strategy will be notified about the death of > a child? > I think, for this thread, that it would be way more interesting to list, in the Akka documentation, to list under which circumstances something is safe to be relied upon. Looking forward to your response > > Again thanks heaps for the discussion and advise... > > >> >>> >>> Any wisdom provided would be greatly appreciated. >>> >> >> Looking forward to answering! :) >> >> >>> >>> Cheers >>> Tino >>> >>> On Monday, January 27, 2014 11:25:14 PM UTC+11, √ wrote: >>> >>>> It's way simpler to just create/wrap another mailbox implementation and >>>> use ThreadLocalRandom with a chance to drop the inbound message on >>>> _dequeue_. >>>> >>>> >>>> On Mon, Jan 27, 2014 at 1:21 PM, Angel Java Lopez >>>> <[email protected]>wrote: >>>> >>>>> First idea: Implement the mailbox using an actor >>>>> >>>>> Actor1 sends messages to ActorRef2 >>>>> >>>>> To simulate drop message, replace ActorRef2 by ActorRef3 that points >>>>> to an actor that forwards message to ActorRef2, but randomly it "lost" >>>>> some >>>>> message. >>>>> >>>>> Angel "Java" Lopez >>>>> @ajlopez >>>>> >>>>> >>>>> On Mon, Jan 27, 2014 at 9:17 AM, Akka Team <[email protected]>wrote: >>>>> >>>>>> Hi Tino, >>>>>> >>>>>> There is no such Mailbox implemented right now, but there are plans >>>>>> to do something like that. We have quite a bit of testing tools for >>>>>> remoting/cluster that emulate various networking problems including >>>>>> completely crazy scenarios. It is not very much documented though and I >>>>>> think they will see some refactoring in the future. >>>>>> >>>>>> -Endre >>>>>> >>>>>> >>>>>> On Wed, Jan 22, 2014 at 1:30 AM, Tino Adams <[email protected]>wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I understand that Akka, like other actor implementations, provides a >>>>>>> at-most-once delivery guarantee. >>>>>>> I was wondering if Akka is shipped with a mailbox implementation >>>>>>> which randomly drops messages for testing purposes. >>>>>>> >>>>>>> How do you guys test your systems for potential message loss, unit >>>>>>> tests only? >>>>>>> >>>>>>> Cheers >>>>>>> Tino >>>>>>> >>>>>>> -- >>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou >>>>>>> p/akka-user >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Akka User List" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> >>>>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Akka Team >>>>>> Typesafe - The software stack for applications that scale >>>>>> Blog: letitcrash.com >>>>>> Twitter: @akkateam >>>>>> >>>>>> -- >>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou >>>>>> p/akka-user >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Akka User List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> >>>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>> >>>>> -- >>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou >>>>> p/akka-user >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Akka User List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> >>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> √ >>>> >>>> * ——————— **Viktor Klang* >>>> *Chief Architect - **Typesafe <http://www.typesafe.com/>* >>>> >>>> Twitter: @viktorklang >>>> >>> -- >>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>> >>>>>>>>>> Search the archives: https://groups.google.com/ >>> group/akka-user >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Akka User List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Cheers, >> √ >> >> * ——————— **Viktor Klang* >> *Chief Architect - **Typesafe <http://www.typesafe.com/>* >> >> Twitter: @viktorklang >> > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > -- Cheers, √ * ——————— **Viktor Klang* *Chief Architect - **Typesafe <http://www.typesafe.com/>* Twitter: @viktorklang -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
