Please let me know whether my understanding is right .
On Thu, Apr 14, 2016 at 5:30 AM, Michael Frank
<[email protected] <mailto:[email protected]>> wrote:
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 a
topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/akka-user/6tWitvQD5sA/unsubscribe.
To unsubscribe from this group and all its topics, 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]
<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.
