Correct, it will limit parallelism. I usually see the streams infrastructure more as a control channel that makes sure that data flows correctly. These kind of control things shouldn't require much overall CPU share so it should not matter so much. If you want to do CPU-intensive work you need to decide where and how to run it anyway (run it asynchronously with `mapAsync`, insert extra async boundaries in the stream, use extra dispatchers, etc).
In the end, the streams infrastructure introduces "just another" layer of CPU scheduling infrastructure into what you have anyways: * OS thread scheduler * Fork-Join-Pool task scheduler * Actor mailbox * and now the GraphInterpreter event execution queue The latter ones are not preemptive which can lead to thread starvation issues when threads (or ActorGraphInterpreters) are blocked. Also fairness can be an issue. An ActorGraphInterpreter has a mailbox but also an internal queue, the mailbox has a throughput setting which defines how long to work on messages before allowing other actors to do other work. Similarly the GraphInterpreter has an "event horizon" which is basically the same but for stream signals. Regarding Akka HTTP, this should not be a problem because data traffic on a single HTTP connection is usually pretty linear: first a request needs to be parsed, then it needs to be handled, then the response needs to be sent out. All of those happen one after each other. But you are right that e.g. for HTTP/2 things can be different. On the other hand, introducing extra asynchronous boundaries for parallelism has a cost, and often it is better to spent that cost on the big picture, e.g. parallelize over multiple connections instead of processing within a single connection. There's a related tricky question whether we should surround all user code with async boundaries to avoid unexpected deadlocks.- Johannes On Thursday, September 28, 2017 at 1:37:22 PM UTC+2, Unmesh Joshi wrote: > > Yeah. I meant ActorRef for GraphStage. My only question then is, if > messages to all the GraphStage Actors get serialized to > ActorGraphInterpreter, will that potentially limit the possible parallel > execution? e.g. If HttpRequestParserStage and HttpResponseRendererStage > both receive actor messages, they will get executed sequentially where it > was potentially possible to handle them in parallel. Its hard to say how > much of benefit this gives, but conceptually, thinking of each graph stage > as a separate actor is simpler as opposed to thinking of a graph of stages > backed by an Actor. > > On Thursday, 28 September 2017 15:59:53 UTC+5:30, > [email protected] wrote: >> >> Hi Unmesh, >> >> On Wednesday, September 27, 2017 at 3:01:24 PM UTC+2, Unmesh Joshi wrote: >>> >>> I was trying to go through the code to understand how GraphStages >>> receive actor messages. I see that GraphStageActor is a actor not created >>> like normal actors. I looks like all the messages to GraphStageActors are >>> wrapped in AsyncInput and passed to ActorGraphInterpreter. This means >>> messages to all the graph stages will essentially be executed by a single >>> ActorGraphInterpreter actor. Is this understanding true? If so, is there is >>> any specific reason for create GraphStageActor the way it is? >>> >> >> I guess you mean the ActorRef created when calling `getStageActor` in a >> GraphStage. Yes, your understanding is correct here. The basic reason is >> that stages that belong to one "fused island" are run together in a single >> actor. Consequently, messages received for those stages also need to be >> handled in the context of that actor to ensure the thread-safety of >> GraphStages. The benefit is that you can access and modify internal state >> of your GraphStage from within the message handler of the stage actor. >> >> Does that make sense? What would you have expected instead? >> >> Johannes >> >> > -- >>>>>>>>>> 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.
