Actors instantiation strategy

[Yann Perchec, Novapost]

Hi!

I would like to know if there is a best practice in actors instanciation : we have a dozen of different actors, each performing a particular operation and and giving the result of this operation to the next actor.

Our first idea was to create a master actor which would institate all actors then starting the process by sending a message to the first actor in the graph. Each actors would get a ref to the next actor by calling system.actorFor on the correct path. The point is we want the next actor resolution to return an actor ref from a group of actors performing the same action like a Router actor do. But it seems that a actorFor does not work when asking a router actor reference?.. Am I correct?

Going further, is this way of instantiating all actors is a good practice versus the way in which each actors instantiate his own child actors? 

In our first idea we would like the fact that each actors references are "shared" between all the actor systems. Plus, it seems easier to monitor the system. 

Would it be possible to have some input on this?

Thanks!

Yann.

[√iktor Ҡlang]

Hi Yann!

On Fri, May 25, 2012 at 10:30 AM, Yann Perchec, Novapost <yann.p...@novapost.fr> wrote:

Hi!

I would like to know if there is a best practice in actors instanciation : we have a dozen of different actors, each performing a particular operation and and giving the result of this operation to the next actor.

Our first idea was to create a master actor which would institate all actors then starting the process by sending a message to the first actor in the graph. Each actors would get a ref to the next actor by calling system.actorFor on the correct path. The point is we want the next actor resolution to return an actor ref from a group of actors performing the same action like a Router actor do. But it seems that a actorFor does not work when asking a router actor reference?.. Am I correct?

How about you send messages to the parent and the parent routes the messages?

 

Going further, is this way of instantiating all actors is a good practice versus the way in which each actors instantiate his own child actors? 

In our first idea we would like the fact that each actors references are "shared" between all the actor systems. Plus, it seems easier to monitor the system. 

Would it be possible to have some input on this?

Cheers,

√

 

Thanks!

Yann.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/mGxAKD8HLkoJ.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Yann Perchec, Novapost]

Hi Viktor!

Thanks for your answer.

The thing is we have three or four potential parents depending on the data type to process, but the parent can then use same child actors during the processing. So we thought it would be a good thing to mutualize actors references between different "actor trees", and doing so, mutualize routers reference.

In fact, with this solution there is no more trees but a circle of routers linked to the master.

But, again, we didn't manage to get routers ref from the actorsystem...

Le vendredi 25 mai 2012 10:47:42 UTC+2, √ a écrit :

Hi Yann!

On Fri, May 25, 2012 at 10:30 AM, Yann Perchec, Novapost <yann.p...@novapost.fr> wrote:

Hi!

I would like to know if there is a best practice in actors instanciation : we have a dozen of different actors, each performing a particular operation and and giving the result of this operation to the next actor.

Our first idea was to create a master actor which would institate all actors then starting the process by sending a message to the first actor in the graph. Each actors would get a ref to the next actor by calling system.actorFor on the correct path. The point is we want the next actor resolution to return an actor ref from a group of actors performing the same action like a Router actor do. But it seems that a actorFor does not work when asking a router actor reference?.. Am I correct?

How about you send messages to the parent and the parent routes the messages?

 

Going further, is this way of instantiating all actors is a good practice versus the way in which each actors instantiate his own child actors? 

In our first idea we would like the fact that each actors references are "shared" between all the actor systems. Plus, it seems easier to monitor the system. 

Would it be possible to have some input on this?

Cheers,

√

 

Thanks!

Yann.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/mGxAKD8HLkoJ.
To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Björn Antonsson]

Hi Yann,

On Friday, 25 May 2012 at 10:47, √iktor Ҡlang wrote:

Hi Yann!

On Fri, May 25, 2012 at 10:30 AM, Yann Perchec, Novapost <yann.p...@novapost.fr> wrote:

Hi!

I would like to know if there is a best practice in actors instanciation : we have a dozen of different actors, each performing a particular operation and and giving the result of this operation to the next actor.

Instead of letting each actor know where to give his result, you could have an actor that is the one who drives the sequence, somewhat like a saga in DDD, a.k.a. the midget in the restaurant.

This saga actor could be modeled as a FSM that sends a message to an actor, goes to the next state, receives a reply, sends that to the next actor, et.c. This way you could easily have multiple different behaviors all using the same processing actors, since they only reply to the sender.

 

Our first idea was to create a master actor which would institate all actors then starting the process by sending a message to the first actor in the graph. Each actors would get a ref to the next actor by calling system.actorFor on the correct path. The point is we want the next actor resolution to return an actor ref from a group of actors performing the same action like a Router actor do. But it seems that a actorFor does not work when asking a router actor reference?.. Am I correct?

I tried this in the repl, actorFor works just fine for routers.

B/

How about you send messages to the parent and the parent routes the messages?

 

Going further, is this way of instantiating all actors is a good practice versus the way in which each actors instantiate his own child actors?

In our first idea we would like the fact that each actors references are "shared" between all the actor systems. Plus, it seems easier to monitor the system. 

Would it be possible to have some input on this?

Cheers,

√

 

Thanks!

Yann.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/mGxAKD8HLkoJ.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

-- 

Björn Antonsson

[Yann Perchec, Novapost]

Hi Björn!

Thanks for your answer.

Your proposition is very interseting. We'll investigate in that way.

For the Router reference, I must have done something wrong.

Thanks again!