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
Thanks for the links.
The repo is not really for beginners, but for people who want to understand
akka http source code. I thought instead of going through all the akka-http
and akka repo, if its possible to carve out a minimal subset, it will be
lot easier for developers. It was of use to our
This is explained in this blog post:
https://akka.io/blog/2016/07/06/threading-and-concurrency-in-akka-streams-explained
and the docs:
https://doc.akka.io/docs/akka/current/scala/stream/stream-parallelism.html#pipelining-and-parallelism
Thanks for sharing your repo, I think it’s a bit weird to
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
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
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
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
