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 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.
