奥尔良无国籍工人

Question

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

Answer 1

Short Answer

You can create a stateless worker by inheriting IGrainWithIntegerKey and using a key 0 .

Long Answer

Stateless workers are the same as normal grains with a couple of differences:

1. They are always activated locally (in the same silo as the caller).
2. Multiple activations can be created if the calls to a stateless worker activation build up.

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:

1. Stateless worker activations may have different 'flavours', which could be related to their key.
2. A larger pool of stateless workers could be activated by addressing them with a range of keys.

But if these features aren't useful to you, the convention is to use a key of 0 .

Answer 2

1. 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.