IPersistentState<T> instances into the constructor of a Grain that they are loaded from the persistence store concurrently during activation? Looking at the code it appears a PersistentStateBridge<T> is created for each IPersistentState<T> instance and those subscribe to the SetupState lifecycle stage. Inside the LifecycleSubject these seem to be started concurrently for a given stage and awaited for using Task.WhenAll. I'm hoping this indeed the case because splitting up state for a single grain is a nice way of reducing the amount of data that needs to be persisted if a logical partitioning is present. The example I have is configuration data and runtime data, where configuration data is only required on activation to configure the work to be done, and runtime data is stored more frequently as work is performed. That gives you a performance boost on the write side so I am hoping the read side on activation is concurrent so there is a read benefit to be had too.
Without persistent state you can't guarantee that there are single instances for something which is purely in-memory.
@ReubenBond can you expand on above statement from :point_up: January 20, 2020 9:06 AM
By Persistent state did you meant grain which are having state using [PersistentState] or similar attribute. I wanted to make sure I am reading it wrong :) Not related to original question but wanted to understand more if there are some nuances which I should be aware of.
The in-built grain directory implementation in Orleans is eventually-consistent, @sammym1982. That can become an issue when the cluster isn't in a steady state and calls for the same grain come in quick success - if nothing is done to mitigate it. The mitigation is persistent state. Any time a grain activation tries to write state, a concurrency check is performed to make sure the grain activation has the latest state (i.e, it has seen all previous writes). If that is not true then an exception is thrown and the grain is deactivating, making the convergence quicker.
Without that mitigation (or something to a similar effect), it's possible for multiple activations of the grain to exist simultaneously for a short period of time. Those duplicates are proactively killed as the directory converges.
ISiloHostBuilder builder = new SiloHostBuilder()
.AddGrainControl()
.UseLocalhostClustering(cBaseSiloPort+instanceNum, cBaseGatewayPort+instanceNum,new IPEndPoint(IPAddress.Loopback, cBaseSiloPort))
Previously I was lacking the third parameter. With that the silos "play nicely together" and stuff works.
ISiloBuilder & IHostBuilder from TestClusters ☺ The implementation is very simple in the end.
@Zeroshi @COCPORN
why couldnt you add an if statement to determine if it should run? @sergeybykov any idea?
Early on, we were concerned about deactivating grains under perceived memory pressure, primarily because it wasn't clear how to measure what amount of memory is actually being used by the app logic as opposed to the amount of Gen2 memory garbage accumulated since the last Gen2 pass of the memory manager. I suspect it should be more clear these days.
It's a bit more than adding an if statement because grains activations are tracked in buckets, from most recently used ones to LRU. Other than that, at least conceptually, it could be a matter of checking for memory pressure (if configured) upon every activation collection cycle and adding an oldest bucket or two for collection.
@Zeroshi
hi @sergeybykov , I was checking in to see if you had a chance to read that essay.
Sorry, I dropped the ball when we suddenly got some snow. I read it now. I think it'd be better for us to chat thematically over Teams/Skype than for me to try to type the same thoughts, and then for us to go back and forth. A voice dialog is an efficient means of arriving to something. 🙂
