"best practice" question Futures and Future.sequence to aggregate data

[Tim Pigden]

I have a web app that needs to return some data aggregated from multiple actors of the same type held by a parent actor.

My current process involves something like 

val requestor = sender

val responses = children.map(_ ? RequestData)

Future.sequence(responses) onSuccess {

  case answer => requestor ! Aggregated(aggregate(answer))

}

Are there better patterns than using future and Future.sequence for this?

[Luis Ángel Vicente Sánchez]

What about Future.sequence(responses) pipeTo requestor

--
>>>>>>>>>> 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+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[√iktor Ҡlang]

Create an actor that aggregates?

--
>>>>>>>>>> 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+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

√

[Tim Pigden]

@Viktor 

I presume you mean spinning up an Actor just to do the single aggregation. Yes I can see the value in that - keeping the functions separate. I guess I'm still thinking of actors as employees with multiple tasks rather than contractors who are just there to do a single job, then quit.

But presumably that still has to do the map / Future.sequence thing because the only alternative I came up with was the clumsier response counting.

Another option - which doesn't suit my current use case is to maintain a permanent aggregation and have it get updated.

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/6aUVvt86g54/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England 
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

[√iktor Ҡlang]

Hi Tim,

On Sat, Jul 26, 2014 at 8:31 PM, Tim Pigden <tim.p...@optrak.com> wrote:

@Viktor 

I presume you mean spinning up an Actor just to do the single aggregation. Yes I can see the value in that - keeping the functions separate. I guess I'm still thinking of actors as employees with multiple tasks rather than contractors who are just there to do a single job, then quit.

Actors should have as few responsibilities as possible, ideally 1.

 

But presumably that still has to do the map / Future.sequence thing because the only alternative I came up with was the clumsier response counting.

For my understanding, why would response counting be clumsier?

It can be encoded as a recursive become:

def aggregate(left: immutable.Set[ActorRef], responses: immutable.Seq[T], replyTo: ActorRef): Receive =

  if (left.isEmpty) {

    replyTo ! responses

    context stop self

    Actor.emptyBehavior

  } else {

    case msg if left(sender()) => context become aggregate(left - sender(), msg +: responses, replyTo)

  }

def receive = aggregate(expectedSenders, Nil, replyTo)

--

Cheers,

√

[Tim Pigden]

Ah. That's a nice pattern.

I suspect recursive become is not in everybody's toolkit. I'm glad I asked the question.

For those of us not so steeped in the whole actor/akka paradigm, perhaps there should be some sort of "Akka Pearls"

[√iktor Ҡlang]

On Sat, Jul 26, 2014 at 11:27 PM, Tim Pigden <tim.p...@optrak.com> wrote:

Ah. That's a nice pattern.

I suspect recursive become is not in everybody's toolkit. I'm glad I asked the question.

Great to hear, happy hAkking!

 

For those of us not so steeped in the whole actor/akka paradigm, perhaps there should be some sort of "Akka Pearls"

Yes, this would be great, would you like to contribute to an effort like that?

--

Cheers,

√

[Tim Pigden]

If it was easy to contribute and somewhat informal - yes. An "akka cookbook" wiki would be good.