Passivation of Actors and Grains

[asynkron]

Passivation of Actors and Grains

[rogeralsing]

Ideas on how to do the actual passivation.

1. The obvious approach is to have something similar to ReceiveTimeout, but didicated for killing idle actors.
   this would give a fairly exact time until the actor is passivated.

2. Another approach could be to per actor, keep track of when it's mailbox last ran.
   And perform a sweep across the process registry, killing off idle actors.
   This would be less exact. but might be cheaper and easier to implement.

Other thoughts?

[hiyelbaz]

What if there are messages coming into the grain mailbox exactly when the grain is about to passivate?

Maybe actor can be recreated where you handle grpc's own timeout exception. (if such a thing exists)

This thread can be useful at some point: grpc/grpc-go#928

Any idea how Orleans handles this?

[RussellLuo]

Per How Activation-GC Works, Orleans just:

periodically scan for activations that have not been used at all for some period of time

And the scan is done by ScanStale(), which is called in an asynchronous task CollectActivationsImpl(). And each grain activation provides a method GetIdleness (), which is based on the internal state becameIdle. Much like approach 2 mentioned above:

2. Another approach could be to per actor, keep track of when it's mailbox last ran.
   And perform a sweep across the process registry, killing off idle actors.
   This would be less exact. but might be cheaper and easier to implement.

For problem 1 mentioned above:

1. What if there are messages coming into the grain mailbox exactly when the grain is about to passivate?

Orleans handles it in this way:

You can also instruct the runtime to deactivate the grain next time it becomes idle, by using:

protected void DeactivateOnIdle()

An activation is considered idle if it is not processing any message at the moment. If you call DeactivateOnIdle while a grain is processing a message, it will get deactivated as soon as processing of the current message is finished. If there are any requests queued for the grain, they will be forwarded to the next activation.

But seems protoactor-go currently has no mechanism to forward (or persist) messages queued in mailbox. (maybe related to #139?)