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

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

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

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

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

2016-10-26 Thread Patrik Nordwall 
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 
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 
> 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 
>> 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 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  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 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.

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

2016-10-26 Thread Richard Rodseth 
Thanks!

> On Oct 26, 2016, at 2:35 AM, Patrik Nordwall  
> wrote:
> 
> 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  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  
>>> 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  
 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 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.
> 
> 
> 
> -- 
> Patrik Nordwall
> Akka Tech Lead
> Lightbend -  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 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.