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<http://doc.akka.io/docs/akka/2.3.0-RC1/java/persistence.html>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/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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - 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.
