ReubenBond on main
PersistentStreamPullingAgent: D… (compare)
It does this.
info: Orleans.Runtime.Catalog Before collection#2: memory=13MB, #activations=3, collector=<#Activations=2, #Buckets=1, buckets=[1h:59m:47s.591ms->2 items]>. info: Orleans.Runtime.Catalog After collection#2: memory=13MB, #activations=3, collected 0 activations, collector=<#Activations=2, #Buckets=1, buckets=[1h:59m:47s.582ms->2 items]>, collection time=00:00:00.0086615.
memoryto tell it to not collect.
IPersistentState<T>instances into the constructor of a
Grainthat 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
SetupStatelifecycle stage. Inside the
LifecycleSubjectthese 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.
IHostBuilderfrom TestClusters ☺ The implementation is very simple in the end.