Is there a way to seperate network resource for different actors in akka remote?

Akka.remote 1.4.7

  • On which platform you are using Akka.Net

Microsoft Visual Studio Community 2019

  • A list of steps to reproduce the issue.

Startup 2 clients which employ akka.remote to communicate between actors as follows, where all actors are extended from ReceiveActor:

Then send a lot of (i.e. 5 millions) messages from actor a to actor c in one thread, while sending several messages from actor b to actor d in another. Even though the two message streams are sent at the same time, messages from actor b cannot be received by actor d in time (i.e. received some minutes after the messages are sent, as it takes minutes for messages from actor a to c to be received).

So are all akka remote messages handled in one messages queue even though they are from and to different actors? Is there a way for messages from actor b to d received in time, i.e. seperate network resource for different actors in akka remote?

Hi @JinQiao

Akka.Net is a completely separate project from Akka, so I can’t say with authority how things work in Akka.Net, but I can describe how they work in Akka on the JVM:

Each pair of nodes in cluster/remoting out of the box, in Akka 2.6, will have a single channel in each direction which all messages between the two goes through, regardless of how many senders and recipients there are on each side.

I don’t think we have seen it as a problem to saturate the network connection with that single channel (at least not with the new remoting Artery), so more connections between a pair of nodes would likely rather create more overhead than make things faster.

There is a special feature if you have one or a few actors that does send very large messages which creates a separate connection for those (https://doc.akka.io/docs/akka/current/remoting-artery.html#dedicated-subchannel-for-large-messages) to avoid head of line blocking. There is also a separate connection for Akka system messages so that those are not affected by user level messages.