ask is fine as long as you don't close over something that is not thread-safe in callbacks of the Future. It should be low risk of mistake in mapAsync since you typically only return the Future (after casting/mapTo to the right type).
I updated the Streams documentation for integration with actors the other day: http://doc.akka.io/docs/akka/snapshot/scala/stream/stream-integrations.html http://doc.akka.io/docs/akka/snapshot/java/stream/stream-integrations.html Regards, Patrik On Tue, Oct 25, 2016 at 11:26 PM, Richard Rodseth <[email protected]> wrote: > I should add that the ask() I would be inserting would actually be to the > ShardRegion for a shared, persistent actor. > > On Tue, Oct 25, 2016 at 11:33 AM, Richard Rodseth <[email protected]> > wrote: > >> Anyone else? Suppose I need a stage that just looks up something that is >> contained in a (persistent) actor. >> Is it good practice to use mapAsync with an ask() to that actor? >> Or is there some other stage that would let me use the actor to transform >> one stream element to another without sacrificing backpressure. >> This SO question advises against making an actor a Processor. >> http://stackoverflow.com/questions/31272267/creating-an- >> actorpublisher-and-actorsubscriber-with-same-actor >> >> >> On Thu, Oct 20, 2016 at 2:55 PM, Richard Rodseth <[email protected]> >> wrote: >> >>> Short version: is it fair to say the traditional warnings against ask() >>> hold less weight because we have back-pressure? >>> >>> In the past I've built an Akka app (no ask() pattern except at the outer >>> edge), and a tool that used Akka Streams (no visible actors except a >>> monitor updated with alsoTo), but am now trying to combine the two concepts. >>> >>> Imagine a service which consumes a Kafka topic, sends an email (service >>> returns Future) and updates an aggregate (persistent Actor). I can imagine >>> an infinite stream for this, with mapAsync generating back pressure from >>> the email service, and the persistent actor as a Sink. Email retries could >>> be handled at the Future level, though I'm still a little unclear on how >>> error scenarios would be handled. >>> >>> But what if the flow needs to thread through other (persistent) actors >>> on the way to the Email service, perhaps to gather some information for the >>> email? >>> >>> Would it make sense to use an ask() here (perhaps in combination with >>> per-request actors). >>> >>> Is it fair to say the traditional warnings against ask() hold less >>> weight because we have back-pressure? >>> >>> Could the command to update the the aggregate persistent actor also be >>> issued with an ask() and acked, leading to a more functional style overall? >>> >>> Advice or examples appreciated. >>> >>> >>> >>> >> > -- > >>>>>>>>>> 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. > -- Patrik Nordwall Akka Tech Lead Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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.
