Reputation: 2927
I am finding it hard to find any detailed documentation on the use of StatelessWorkers.
I want to achieve something similar to this. As suggested in the document I need to use Stateless Workers in order to process some messages and activate the grains that will eventually hold the state.
I would like to have multiple instances of a dispatcher grain processing the "initialization" since this grain by no means handles any state and the messages do not need to be queued in order.
Do I need to mark this grain as Reentrant? or Will the StatelessWorker (attribute) be enough?
With regards to activation, it seems like I need to inherit from IGrainWithIntegerKey
(or a similar interface). this means that I need to activate the grain as follows:
GrainClient.GrainFactory.GetGrain<IDispatcherActor>(0)
Since I am always using 0 as ID will multiple instances of the grain still be activated? or do I need to create different IDs. It seems like I cannot call the grain as follows:
GrainClient.GrainFactory.GetGrain<IDispatcherActor>()
even if I inherit from IGrain
Upvotes: 5
Views: 1918
Reputation: 2353
You can create a stateless worker by inheriting IGrainWithIntegerKey
and using a key 0
.
Stateless workers are the same as normal grains with a couple of differences:
They are subject to the same deactivation semantics.
It might be surprising that stateless workers have keys, but there are couple of reasons why keys might be useful:
But if these features aren't useful to you, the convention is to use a key of 0
.
Upvotes: 9
Reputation: 96
- They can only be called from inside a silo.
StatelessWorker grains can be called from clients. That's actually one of the popular scenarios when calls from clients should be preprocessed before they can be routed to other grains for actual processing.
Upvotes: 3