By induction you can conclude that messages order is guaranteed when sending sequentially (in the same thread) by using the following assertions:
- Messages sent to any local actor go immediately to their destination inbox hence order is preserved because of sequential execution - JMM rule. - Messages that go from node A to node B will be sent in the same order as they arrive to node A remote dispatcher's inbox which for an actor hosted at node A, the order of arrival is preserved (apply previous rule) - Messages that arrive to node B will be put in the remote dispatcher inbox in the same order they arrived, apply first two rules and you that concludes in the messaging ordering rule - as for remote, current remote implementation when sending from node A to B, it can only send synchronously hence, order is also preserved. The most complicated rule is the last one, but once order from node A to node B is preserved then you can conclude that order messages from actor A to actor B is also preserved regardless of their location. This is my explanation with my own words, the documentation I think explains it using the Java Memory Model as a reflection. HTH, Guido. On Wednesday, September 7, 2016 at 9:50:59 PM UTC+1, Justin du coeur wrote: > > On Wed, Sep 7, 2016 at 3:47 PM, Patrik Nordwall <[email protected] > <javascript:>> wrote: > >> The documentation is talking about actor pairs, because you normally send >> messages from an actor. In this example you don't send them from an actor, >> but that doesn't matter. The tell methods are called in a specific order >> since you invoke them from the same thread. Same would happen if the code >> were running in an actor. >> > > Huh -- this is something I hadn't known. Can you count upon the general > principle that "messages sent from a single thread to a given Actor will > arrive in the order they were sent"? I'm not really *surprised* if that's > true (and I suspect I've implicitly assumed it without thinking about it a > few times), but I don't think I've ever seen it stated in those terms, and > it's useful to know one can count on it. It's probably worth stating in as > many words *somewhere* in the docs if it's not already there... > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
