Method to block Migration of Cluster Sharded Actors in a Certain State

[kraythe]

I have a cluster shared actor that basically has two states; IDLE and BUSY. The actor is cluster shared because I need the behavior of having only a single one of these in the cluster per user and  I want all of the messages that the actor to handle to be serialized per user. The actor mostly sits on IDLE but when it gets a certain message it becomes BUSY. During the busy state, it is collecting information from several other actors through tell() calls and waiting on the response messages. During the BUSY state I do NOT want that actor changing nodes. If it did then it would basically have to start all over processing the message it was holding in the busy state. Furthermore, persisting the actor's state is a non-starter as the data it is collecting is quite large, other actors are sending it references to immutable data in the same VM, after it gets all the data it does some analysis, writes a record, and is done. 

So the question is, if a node falls out of the cluster (or a new node joins) while the actor is BUSY and the rebalancing of the system starts to happen, can I prevent the actor from moving to the new node until after it goes back to IDLE. 

Thanks a bunch. 

-- Robert

[Patrik Nordwall]

You can define a custom handOffStopMessage that your actors will receive when they are asked to stop for rebalance. You can delay the stop when receiving that message by not calling context.stop(self) until you are done. 

Note that if you don't stop within the handOffTimeout the rebalance will be aborted.

Also note that other entities within the same shard will also be asked to stop so one "slow" entity will affect others. You should probably not have too long such delays.

It's more robust to design the system so that can always crash and recover independent of what state it is in. Then such rebalance in the middle of a process should not be a problem.

Cheers,

Patrik

--
>>>>>>>>>> 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 akka-user+unsubscribe@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Patrik Nordwall
Akka Tech Lead
Lightbend -  Reactive apps on the JVM
Twitter: @patriknw

[kraythe]

So if I have an actor that while on a specific state simply stashes any message that it doesn't handle, will it ignore the stop request until the message is I stashed and processed? Although that time delay should be a max of a couple seconds it does exist. And in the meantime j don't want the actor waiting for the reply to be never replied to because the message got dumped when the actor moved.

The thing is the actor ends up only in this state due to a request from another actor and although I could get a receive timeout and try again, I would prefer to not do that if it can be avoided.

[Patrik Nordwall]

The stop signal is that the actor is terminated, i.e. you called context.stop, so stashing is fine

fre 2 sep. 2016 kl. 16:46 skrev kraythe <kra...@gmail.com>:

So if I have an actor that while on a specific state simply stashes any message that it doesn't handle, will it ignore the stop request until the message is I stashed and processed? Although that time delay should be a max of a couple seconds it does exist. And in the meantime j don't want the actor waiting for the reply to be never replied to because the message got dumped when the actor moved.

The thing is the actor ends up only in this state due to a request from another actor and although I could get a receive timeout and try again, I would prefer to not do that if it can be avoided.

--
>>>>>>>>>>      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 akka-user+...@googlegroups.com.