Adds support to use MayInterleave
with StatelessWorker
grains
#9050
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since
MayInterleave
predicate is handled as a component, and components are not allowed in SW grain context. UsingMayInterleaveAttribute
, orleans throws an exception as detailed here #9049 - It is understandable to not allow components to be registered with SW's, since they may interplay with the grain's state, and SW use-case is not to dealing with state.I think the constraint can be relaxed here since the interleaving operation is determined on every message invocation, and the method that determines that is defined as
static
and is purely functional, there should not be any problems AFAIK.Personally I would go with a custom thread-safe singleton, but I can understand people using
StatelessWorker**(1)**
as a means to have a single worker-per-silo that is inherently thread-safe due to Orleans' scheduler, yet still wanting the interleaving benefits.Fixes #9049
Microsoft Reviewers: Open in CodeFlow