insylogo
commented
10 months ago While we're talking about enhancements here, I'd love to be able to know when, after MigrateOnIdle is called, the grain has been migrated. All the lifecycle participation business seems pretty hardcore and I'd love to be able to return some awaitable Task to the caller who triggered the MigrateOnIdle event that, when that Task is complete (successfully..) I can be certain that the grain has migrated. Right now I've got some logic that says "If something something, trigger the process that migrates the grain. Now, wait 150 milliseconds. Retrieve a new grain reference and try calling the grain now" and mostly that works, but sometimes when things are really busy, the grain doesn't become idle and get migrated for awhile, and I'd rather not have to poll for when that is done.
ledjon-behluli
franckyj
There should be an easy way for a caller to migrate a grain if the call is remote, or possible for any other reason. The functionality was merged by https://github.com/dotnet/orleans/pull/8452 but it clearly states that there is no policy for automatic migration.
Our situation is related to silos handling messages from event hub partitions. There is a direct relationship between silos handling partitions and where the grains are hosted (in our case we use the local placement strategy). Is the partitions ownership change we should "migrate" the grains to make sure they are hosted on the silo handling their messages.
I don't really know "how" this should be done, but a few ideas come to mind.
Here is the discord question, for context.
We also have the concept of "container" grains that have a list of grain ids that should be grouped together. If we want to push this migration concept further, we could think of a way to make a group of grains be migrated together. But having only the "automatic" migration feature for a single grain as opposed to a group of grains would be a great start.