Hmmm, one connection eliminates the ordering concern, to take that into account when the akka remote is re-written, it would be nice to have more than one connection between two nodes but then the TCP sender needs to be passed some extra information to decide which connection to use to guarantee the akka documented order of events.
On Tuesday, February 2, 2016 at 11:36:14 AM UTC, drewhk wrote: > > HI Guido, > > On Tue, Feb 2, 2016 at 11:40 AM, Guido Medina <[email protected] > <javascript:>> wrote: > >> Hi, >> >> I recently read there is a Netty single channel between nodes to strongly >> guarantee message ordering, is that true? >> > > There is one TCP connection, the Netty channel does not come into the > picture (it is just a library that provides abstractions in our case to > work with TCP). > > >> >> My other concern is about message ordering when using remote/cluster >> extensions: >> >> Say there are N channels between *node_1* and *node_2*: >> >> - How is a channel selected when I send a message from >> *actor_A@node_1* to *actor_B@node_2*, is the channel always the same >> on *node_1* to guarantee the ordering for that pair? I'm assuming >> yes, making this question to lead to a more complex question. >> >> There is one TCP connection. That connection is used to send the > messages. All messages from all actors are going through that connection, > sequentially. > > > >> >> - Lets now say that I have a round-robin local router which created >> *actor_1..N@node_1, >> N = CPUs* and messages are processed on each copy actor of that >> router, how is a channel selected if each of these actors say >> *actor_B.tell(message, >> noSender())*? but what I'm trying to figure out is if that set of >> actors use the same channel making* noSender()* create a contention >> side effect? >> >> If *noSender()* has a bad side effect it should be said on the >> documentation, it could be that it is treated as something special and then >> from the context the real sender is used to identify what channel it is >> going to be used. >> >> Now if there is only a Netty channel to guarantee message ordering, why >> not pick the channel base on the hash of the pair composed by sender and >> recipient? >> > > There are no subchannels in TCP. Having subchannels means implementing an > additional layer to implement a MUX/DEMUX protocol and additional framing > (otherwise large messages cannot be interleaved with small ones). We had > plans for this (and for many other things) but had no time or resources. > > Or maybe I misunderstood you and you actually meant multiplexing over > different TCP connections? > > >> That will still guarantee the message ordering that is officially >> documented and reduce contention considerably IMHO. >> > > There are plenty of things that we can theoretically do but all I can do > now is to relay such requests. > > -Endre > > >> >> Best regards, >> >> Guido. >> >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > -- >>>>>>>>>> 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.
