Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Actors instantiation strategy
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  5 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Yann Perchec, Novapost  
View profile  
 More options May 25 2012, 4:30 am
From: "Yann Perchec, Novapost" <yann.perc...@novapost.fr>
Date: Fri, 25 May 2012 01:30:13 -0700 (PDT)
Local: Fri, May 25 2012 4:30 am
Subject: Actors instantiation strategy

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.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
√iktor Ҡlang  
View profile  
 More options May 25 2012, 4:47 am
From: √iktor Ҡlang <viktor.kl...@gmail.com>
Date: Fri, 25 May 2012 10:47:42 +0200
Local: Fri, May 25 2012 4:47 am
Subject: Re: [akka-user] Actors instantiation strategy

Hi Yann!

On Fri, May 25, 2012 at 10:30 AM, Yann Perchec, Novapost <

yann.perc...@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,

--
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Yann Perchec, Novapost  
View profile  
 More options May 25 2012, 5:12 am
From: "Yann Perchec, Novapost" <yann.perc...@novapost.fr>
Date: Fri, 25 May 2012 02:12:00 -0700 (PDT)
Subject: Re: [akka-user] Actors instantiation strategy

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 :


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Björn Antonsson  
View profile  
 More options May 25 2012, 5:15 am
From: Björn Antonsson <bjorn.antons...@typesafe.com>
Date: Fri, 25 May 2012 11:15:01 +0200
Local: Fri, May 25 2012 5:15 am
Subject: Re: [akka-user] Actors instantiation strategy

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.perc...@novapost.fr (mailto:yann.perc...@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/

--  
Björn Antonsson
Typesafe (http://www.typesafe.com) - The software stack for applications that scale

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Yann Perchec, Novapost  
View profile  
 More options May 25 2012, 5:30 am
From: "Yann Perchec, Novapost" <yann.perc...@novapost.fr>
Date: Fri, 25 May 2012 02:30:39 -0700 (PDT)
Local: Fri, May 25 2012 5:30 am
Subject: Re: Actors instantiation strategy

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!

Le vendredi 25 mai 2012 10:30:13 UTC+2, Yann Perchec, Novapost a écrit :


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »