One thing to add here is that we prefer to talk about reliability instead of guarantees. The practical consequence in this case is that while we reliably deliver the Terminated message (and failures, internal signals etc.), it might not actually get into the mailbox if you happen to configure a bounded one and it is full. Or your JVM might run out of memory. Therefore we cannot really give hard guarantees, because we know that there are certain (rare) conditions under which they do not hold. Reliability is always about how unlikely the failure case is, not a black and white property (which would be the interpretation of the word “guarantee” in German or Swedish).
Regards, Roland 1 feb 2014 kl. 08:24 skrev Patrik Nordwall <[email protected]>: > Message delivery guarantees are documented here: > http://doc.akka.io/docs/akka/2.3.0-RC1/general/message-delivery-guarantees.html > > System messages, such as watch, terminated, supervision, are using reliable > delivery. > Terminated is a system message, and it will also be delivered in the case of > network partitions or JVM crash, because of remote death watch. > > For at-least-once semantics of user messages you can use akka-persistence > channels, or replicate messages with persistent views. > The persistent channel can send back an acknowledgement when it has received > the message, i.e. when it is stored in the journal. > > Regards, > Patrik > > > > 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. 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. > > > 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? 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? > If I can't even rely on "system" messages being received by the Actor then > I'm at a total loss here. > > > > 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. I'm not negotiating ACID guarantees with my DB > depending on the circumstances, I rely on it come rain or shine. > 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) > 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. > > 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 :) > > 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? > > 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/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. > > > > -- > 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/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. > > > -- > >>>>>>>>>> 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 > > 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 > > 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. > > > > -- > > Patrik Nordwall > Typesafe - Reactive apps on the JVM > Twitter: @patriknw > > > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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.
