Re: [akka-user] Combining Kafka, Akka Streams and (Persistent) Actors

2016-10-21 Thread Justin du coeur
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

Re: [akka-user] Combining Kafka, Akka Streams and (Persistent) Actors

2016-10-21 Thread Richard Rodseth
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: >

Re: [akka-user] Combining Kafka, Akka Streams and (Persistent) Actors

2016-10-21 Thread Richard Rodseth
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

Re: [akka-user] Combining Kafka, Akka Streams and (Persistent) Actors

2016-10-21 Thread Justin du coeur
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

[akka-user] Combining Kafka, Akka Streams and (Persistent) Actors

2016-10-20 Thread Richard Rodseth
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