Thank you

On Thu, Apr 14, 2016 at 10:19 PM, Michael Frank <[email protected]>
wrote:

> reply inline.  hopefully this makes my solution more clear.
>
> -Michael
>
> On 04/14/16 02:37, Mahesh Govind wrote:
>
> Thank You .
>
> So in case 1 , you are recommending the child to send a message to
>  controller when it gets a leave message .
>
>
> no.  i would use the same message flow as you described in your original
> email.  the only change i would make is instead of:
>
> "controller will do getContext().getChild("networkdevice_IP") and get the
> right FSMActor."
>
> i would instead get the child ActorRef by consulting the map, then
> immediately remove the child from the map.  by 'immediately' i mean remove
> the child from the map in this iteration of the actor receive loop.  since
> actors process their messages synchronously, there is no chance of
> inconsistency.
>
> The map(IP->actor) is maintained by controller .Controller will remove the
> child from map and kill the child ?
>
>
> yes.
>
> Since controller is processing messages one by one there will not  be any
> inconsistency ?
>
>
> yes.
>
>
>
> Please let me know whether my understanding is right .
>
>
>
>
> On Thu, Apr 14, 2016 at 5:30 AM, Michael Frank <[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].
>> To post to this group, send email to <[email protected]>
>> [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>
>> 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].
>> To post to this group, send email to <[email protected]>
>> [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/>http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives:
> <https://groups.google.com/group/akka-user>
> 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.
>
>
> --
> >>>>>>>>>> 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].
> 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.
>

-- 
>>>>>>>>>>      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.

Reply via email to