Cool, thanks for sharing, nice stuff :) We know, btw., that some pieces of the architecture are not completely optimal but are consequences of the history of the projects. E.g. it could make sense to write a streams-only implementation of the TCP layer instead of putting it on top of the actor based Akka IO.
One thing that seems to be missing in your project is support for streaming HTTP bodies. This is somewhat essential to the whole architecture because it shows how while reading the request body (or writing the response body), backpressure needs to be kept up through all the layers. Johannes On Thursday, September 28, 2017 at 7:09:43 PM UTC+2, Unmesh Joshi wrote: > > Thanks, this makes it clear. > Btw, one thing I am trying to understand is, when will be the stream not > 'fused'? When 'async' boundaries are inserted? > > On a separate note, I am trying to create a very thin slice through Akka > HTTP, Akka Streams, Akka IO and Java NIO. A very simple Http server which > handles only GET requests to return Hello World response. The aim is to > give developers minimal executable code (< 20) to look at and experiment > with to understand Akka Streams, Http and Akka IO. > > I am hoping to improve it with some documentation. Please let me know if > you think this will be helpful. > https://github.com/unmeshjoshi/reactiveio > > > > On Thursday, 28 September 2017 17:25:33 UTC+5:30, > [email protected] wrote: >> >> 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.
