On Fri, Oct 21, 2016 at 10:32 AM, Richard Rodseth
wrote:
> I've had no problems using Futures within actors and piping the result to
> the actor, after mapping. I have had problems when an actor gets flooded
> and you get timeouts because you're simply starting up too many
Isn't your comment about "messes up the pseudo-single-threading invariant
of Actors" more about not closing over mutable state? In any case, you
can't avoid Futures if you're using Slick or HTTP clients, for example.
On Fri, Oct 21, 2016 at 7:32 AM, Richard Rodseth wrote:
>
I've had no problems using Futures within actors and piping the result to
the actor, after mapping. I have had problems when an actor gets flooded
and you get timeouts because you're simply starting up too many Futures.
That, I think, is where back-pressure changes the landscape.
Thanks for the
On Thu, Oct 20, 2016 at 5:55 PM, Richard Rodseth wrote:
> Short version: is it fair to say the traditional warnings against ask()
> hold less weight because we have back-pressure?
>
Well, keep in mind that at least some of the usual warnings against ask()
have nothing
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