This section of the documentation shows how to place blocking code on a dedicated dispatcher:
http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/scala/stream-integrations.html#Integrating_with_External_Services On Fri, Feb 5, 2016 at 12:14 AM, Endre Varga <endre.va...@typesafe.com> wrote: > > > On Fri, Feb 5, 2016 at 3:30 AM, Gabor Dorcsinecz < > gabor.dorcsin...@gmail.com> wrote: > >> Hi Guys, >> >> I have some missunderstandings regarding akka streams. >> I somebody could just clear them up, would be very nice >> 1. Are streams actually based on actors, or is it something completely >> different? >> > > Streams are themselves just a description/blueprint, they don't execute. A > Materializer maps these blueprints to actual executing entities. The > default, and currently only one implementation maps graph processing stages > to actors. By default, the system tries to cram all of your graph into one > actor except: > - ActorPublisher/Subscriber are always distinct actors > - subgraphs marked with AsyncBoundary are not sharing their actor with > stages outside the subgraph > - similar to AsyncBoundary, setting a dispatcher on a subgraph means that > it will execute on a dedicated actor. > > See > http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/scala/stream-flows-and-basics.html#Operator_Fusion > for details > > >> 2. I see the ActorProducer / ActorSubscriber classes, but also see the >> construction of graph stages which handle similar stuff. How do these >> relate? >> > > ActorPublisher/Subscriber are earlier abstractions. They allow you to > define a Source or Sink in terms of an Actor. > > The benefits > - If you are familiar with actors, this style might be easier to > understand > - you can extend interfaces/abstract classes that require an Actor (e.g. > persistence classes) > > The drawbacks > - They are not fusable with the rest of the graph, they will be always a > standalone actor > - Their API is a bit more clunky compared to stages which were explicitly > designed for stream-processing > > Stages benefits > - They are fusable > - They can also expose an ActorRef, acting like an actor to the external > world > - API hand taylored to stream processing > - Can express other shapes than source and sink > > Drawbacks > - different API from actors, needs some time to get used to > - cannot extend actor related classes > > > >> 3. It is a bad habit, to do blocking things in actors, because they will >> eat up the thread pool underlying actors. Is the same true for flows? >> > > Yes. All threadpool backed designs have this limitation, this is not just > about actors. It is theoretically possible to create a materializer that > maps each stage to its own thread though. If you have blocking stages, you > should put them on a dedicated dispatcher. > > In general, our view of blocking ("don't do it") haven't changed. > > >> Can I just run a query in a flow stage that takes say 2 minutes? >> 4. How does akka http works? I mean all akka streams are about the >> consumer is pulling the data. But in akka http - which is based on streams >> - >> there is nobody pulling. If I have a server, somebody is just pushing >> stuff to me. So how does these come together? >> > > This is not true. TCP is implicitly pulling by only ACK-ing frames if > there is space in the receive buffers. Once the buffer is full, TCP > backpressures the sender side until the application reads some data from > this buffer -- and hence implicitly "pulls" the sender side, in this case > the next fragment of an HTTP request (for short requests the buffer is > capable of absorbing them, but this doesn't change the logic). There is no > "just pushing" because TCP is a backpressured protocol and TCP receive > buffers are bounded. > > -Endre > > >> >> Thanks, Devorb >> >> -- >> >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. >> To post to this group, send email to akka-user@googlegroups.com. >> 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 akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
