Reuben Bond

@oising's activation shedding package ought to help with that: https://github.com/oising/OrleansContrib.ActivationShedding I would suppose that in your case you have a fairly fixed set of grains which are active at all...

> However, it is stated above in this issue that "voluntarily deactivating the grain will not likely cause that grain to be reactivated on a different silo because caches will...

Yes, the approach which we plan for 4.0 is an atomic directory update.

Calls (long-running or not) will need to complete before migration. As shown above, migration follows the regular deactivation path, so this is not related to migration in particular. If calls...

How long are these long-running calls that you speak of and how frequently do you expect the cluster to be rebalancing?

> Does that hold true if the "next call" is already queued waiting for the current call to complete when `Grain.DeactivateOnIdle` is invoked? > What if the grain is re-entrant...

This is a good idea. I wanted the attribute name to be very clear about its purpose (it causes a serializer to be generated), but `[OrleansSerializable]` is likely a better...

Maybe we should bundle codegen in by including it as a dependency of the package which holds the attribute itself. It's one of the things which trips up more people...

LGTM. cc @benjaminpetit for feedback. I made some minor adjustments in the latest commit.

@benjaminpetit PTAL. I recall you had an opinion that this should be implemented using a delegate instead. I wonder how that fits with the `InitializeAsync` method: should the delegate return...