Hi,

On Fri, Apr 18, 2014 at 10:55 AM, Alexey Shuksto <seig...@gmail.com> wrote:

> Hello fellow hAkkers,
>
> In our project we use same business logic several times:
>
>    1. Manager actor `M` receives work order `WorkOrder(n, time)`;
>    2. `M` distributes work over `n` worker actors `W` (`n` differs
>    mostly);
>    3. After all work is 'done' or specified amount of `time` had passed,
>    some entity must gather all 'done' work, reduce it and sent further down
>    workflow;
>    4. By 'done' I mean that `W` could either do its work correctly, or
>    fail internally, or just not do work in `time` -- all is perfectly
>    normal.
>
> Right now it is done via third gatherer object `G`:
>
>    1. `G` is FSM with 2 states: `Wait` and `Gather`;
>    2. `G`s is instantiated in `M` context and every `M` actor holds a
>    fixed size queue of `G` actors in `Wait` state (to prevent flood of
>    work orders);
>    3. When distributing workload, `M` also sends work order to `G` and
>    orders every `W` to forward results to `G`;
>    4. On receive of work order, `G` switches to `Gather` state `forMax`
>    `time`;
>    5. After receiving every work result, `G` check if all necessary work
>    was done, and if it is, sends itself `Done` message;
>    6. On `Done | StateTimeout` message, `G` reduces all received results,
>    sends it further down, switches to `Wait` state and sends itself to 
> `M`actor to be placed in queue.
>
> While this particular scheme works well enough, I was wondering -- maybe
> we overlooked more easy and straightforward one?
>

That looks good.


>
>
> For example, we could implement `G` not as FSM, but as simple
> 'short-living' actor which destroys itself after reduce,
>

Yes, that is how I would do it, and only do the pooling if I had evidence
that it is needed for performance reasons.


> but this produces several questions:
>
>    1. What would be CPU, memory and GC overhead for continually
>    create/destroy, say, 1k actors per second?
>
> Try it, measure!
We have previously measured actor creation to 20 micro seconds (average of
100000 actors).

>
>    1. Do `ActorContext.actorof(..)` blocks for entire actor creation
>    time, or just for time enough to produce ActorRef for a future actor?
>
> the construction is async (constructor will potentially run in another
thread)

>
>    1. What to do with (possibly high) number of `W` messages to
>    `deadLetters` with results obtained after `time` had passed and
>    corresponding `G` actor is stopped?
>
> well, if that is problem for some reason you can keep it alive for some
extra time to absorb late messages, e.g. setting receiveTimeout

/Patrik

>  --
> >>>>>>>>>> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe <http://typesafe.com/> -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! <http://www.scaladays.org/>
Scala <http://www.scaladays.org/>
Days <http://www.scaladays.org/>
June 16th-18th, <http://www.scaladays.org/>
Berlin <http://www.scaladays.org/>

-- 
>>>>>>>>>>      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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to