ATE currently requires an explicit API call to suspend Actors, which works well for use cases where there is an external controller that knows clear resume and suspend lifetime cycle. This works less well for long-living but mostly idle Actors where we will want to be able to integrate automatic suspension via externally observable signals, such as request traffic or system activity (CPU).
There are a couple of layers/choice to this:
Does this functionality have to be built vertically into Substrate in a deep integration or we expose the right surface area to allow someone to implement this easily? Specifically, does Substrate offer just an API for idle suspend or enables enough visibility/triggers into Actor behavior that it is easy to build and integrate with.
An idle suspend API should be built that is generic to the idle signal: IMO it would be bad to have separate "idle suspend due to network", "idle suspend due to CPU" etc that are not coordinate with each other.
ATE currently requires an explicit API call to suspend Actors, which works well for use cases where there is an external controller that knows clear resume and suspend lifetime cycle. This works less well for long-living but mostly idle Actors where we will want to be able to integrate automatic suspension via externally observable signals, such as request traffic or system activity (CPU).
There are a couple of layers/choice to this:
Does this functionality have to be built vertically into Substrate in a deep integration or we expose the right surface area to allow someone to implement this easily? Specifically, does Substrate offer just an API for idle suspend or enables enough visibility/triggers into Actor behavior that it is easy to build and integrate with.
An idle suspend API should be built that is generic to the idle signal: IMO it would be bad to have separate "idle suspend due to network", "idle suspend due to CPU" etc that are not coordinate with each other.