Hi Shawn, The use case you're referring to (transitive ordering) I think traditionally is accomplished in the actor model with the use of "arbiters": https://en.wikipedia.org/wiki/Indeterminacy_in_concurrent_computation I.e. you need a single source of truth w.r.t. the ordering, and since Actors are "islands of order in a sea of chaos" you "just" need A and B to agree on an intermediary when communicating with C, as you say, remoting would otherwise be very interesting (and different mailbox implementations may give you different semantics). Burdening all communication with acks (which could get lost as well, and the original message too) just because it is needed in some cases, would not be responsible :)
In general, with your coworker, I suspect it is a matter of mapping problems to solutions rather than solutions to solutions (i.e. it may not be meaningful to map all solution in his/her world to the world of actors, but instead focus on how certain problems are solved with actors and then he/she can do the mapping from other-technology-prefered solution to the actor-solution themselves) Does that make sense? On Sat, May 23, 2015 at 4:41 PM, Shawn Garner <[email protected]> wrote: > I was talking with a coworker and he has some custom behavior he can't > understand how to do anything useful without. > He want's an tell message (a') sent from A -> C to not allow actor A to > continue until after there is confirmation that A's message is in C's > mailbox. > This way if a sends (a'') to from A -> B and B sends a message (b') fro B > -> C that C should process messages always in the defined order a',b'. > I was looking at the mailboxes and it sees like even if you use the > UnboundedPriorityMailbox and it seems to me that with a tell message it > probably is not blocking the sending actor but some kind of internal > component of Akka. > So I'm thinking UnboundedPriorityMailbox breaks down when you start > talking remote actors and http actors in that the first one deserialized > would block the other one but not block the sender until the message is in > the mailbox. > Also I'm thinking that UnboundedPriorityMailbox will just order messages > sitting in the mailbox. If b' arrives before a', then b' may already be > removed from the mailbox and being processed which the blocking and > ordering of UnboundedPriorityMailbox will do nothing to help. > Could you help me understand this? > Is there anything built into Akka would give you this guarantee of order? > Or would I have to build this in yourself with some kind of ack system > with an ask vs a tell message waiting to send a'' until a' was ack'd as > recieved and delegated to another worker actor D? > My co-worker seems fixated on these aynch semantics because he want's it > to behave like an asynch queue of ActiveMQ and feels Akka should provide > something like that out of the box. > I told him I don't think so but you get all the tools to build it yourself > whatever semantics you want. > > Thanks, > Shawn > > -- > >>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Cheers, √ -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
