I can think of two solutions.
1. in your controller actor, maintain a separate mapping of
"networkdevice_IP" -> ActorRef. when you create a new child actor,
don't give it a name, let akka pick a random unique name, then add the
mapping. when routing messages to the child, instead of using
getChild(), look up the actor ref in your map. when a child leaves,
remove it from the map immediately, then stop it asynchronously by
sending the 'leave' message.
2. in your controller actor, track child actors which are leaving, and
stash messages destined to these actors until you receive termination
confirmation. you could again keep a mapping of "networkdevice_IP" ->
ActorRef, but this mapping would only hold actors which are leaving.
when you receive a message for a child, first check if the child is
leaving: if so stash() the message. if the child is not in the leaving
map, if the child exists, send the message to it. if the child doesn't
exist, create it. when a child is leaving, put a watch on the child
using context.watch(), add the child name to the leaving map, then send
the 'leave' message to the actor. when you receive the deathwatch
Terminated() message, call unstashAll() to flush any stashed messages.
i have used the first solution many times, its quick and easy. solution
two is applicable however if you are modeling a resource which cannot
have two separate incarnations running at the same time.
-Michael
On 04/13/16 01:15, Mahesh Govind wrote:
Dear Experts ,
Could you please help me with a right design choice for the following
scenario.
*Use case * : 1000's of Network device are controlled by a network .
* Network devices will join and leave the network by sending *Join*
and *Leave* messages respectively to the network controller.
*Joining scenario*
* When controller get a *Join* message from a network device ,
* it will check whether an FSM actor exists for that network device
by calling getContext().getChild("networkdevice_IP").
* "networkdevice_IP" is used to identify the actor.
* if the child lookup returns null , a new FSMActor will be
spawned and join message is processed by the new FSMActor
*
Leaving scenario*
* Network device will send a *Leave* message to the controller
* controller will do getContext().getChild("networkdevice_IP") and
get the right FSMActor.
* sends “*leave* message" to this actor.
* While processing Leave message , FSM actor will terminate itself
by calling stop() .
*Complication*
* Now there is a possibility that while the stop() is being
processed by FSMActor , a new Join may come from same network
device (networkdevice_IP).
* Since stop() is asynchronous getContext().getChild(network
device) will still return the FSMActor (networkdevice_IP) , but if
we send message to this actor , the message will go to DeadMessages.
*
*Design question .*
* How to handle such scenario using AKKA ? So that we will not
return a stale Actor using getContext().getChild()
* [one possiblity might be to leave this corner scenario and let the
network protocol to handle this with retransmission .But if
retransmission is not there what to do ?]
With thanks and regards
Mahesh
--
>>>>>>>>>> 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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
