Raghu
Raghu

Reputation: 3069

What is the max number of actor instances for a given actor id for a given actor at any time in service fabric cluster?

I am trying to understand the maximum number of actor id instances that will be executing a given method (on given actor interface) at any time in a given service fabric cluster. Here is my example:

  1. Lets say that I just defined an actor class called CustomerActor that derives from service fabric's Actor and implements ICustomerActor interface which has a single method called Process.
  2. Lets say that I have a client that sends message to ICustomerActor.Process method by using actorIds based on customer id. For this example, my customer id range is between 1 and 99. Therefore my actor id range is Customer/1 through Customer/99.
  3. Lets say that CustomerActor is configured with number of partitions = 9 and number of nodes = 3, meaning there may be 3 partitions per node.
  4. Assuming equal distribution of customer actorIds across all partitions, lets assume that partition 1 will serve customer ids 1 through 99/9 = 11, partition 2 will serve customer ids 12 through 22 etc.
  5. Lets assume that cluster was chugging along fine with equal distribution and no node failures occur for the purpose of this discussion.
  6. Now all of a sudden the client starts sending multiple requests (in quick succession) for a particular customer id (for whatever reason), say, Customer/8, which is in partition 1 and assume that cluster is currently only servicing customer/8 requests.
  7. Lets say that client just sent 20 requests for actor with id Customer/8. Except for this customer actor id, there is no other traffic in the cluster.
  8. Lets say the client could send all above requests (without blocking on client side) because we are using reminders in CustomerActor class, which returns the control back to client immediately.

Here are my questions:

  1. Since actor model guarantees single thread programming, will there be only one instance of CustomerActor (mapped to actor id: Customer/8) that executes ICustomerActor.Process method in the entire cluster?. If so, does this mean there may be 19 requests queued up at most (assuming the 1st request has not finished yet)?

  2. Or will there be 3 instances (one per node) of CustomerActor (all mapped to actor id: Customer/8) that execute ICustomerActor.Process method simultaneously in the entire cluster? If so, does this mean there may be 19/3 requests queued up at most (assuming the 1st request on any node has not finished yet)?

  3. Or will there be 9 instances (one per partition across all nodes) of CustomerActor (all mapped to actor id: Customer/8) that execute ICustomerActor.Process method simultaneously in the entire cluster? If so, does this mean there may be 19/9 requests queued up at most (assuming the 1st request on any partition has not finished yet)?

  4. Or is there another behavior that I have not accounted for?

Upvotes: 3

Views: 1218

Answers (1)

LoekD
LoekD

Reputation: 11470

  1. There's one instance of one Actor, using one ID. Actor access is indeed 'single threaded access', so requests are queued up. (this answer is how it works)
  2. Actors are hosted inside an ActorService (stateful service), which has primary and secondary replicas. Actors themselves have no primary/secondary concept. ActorID determines the partition of the ActorService it's hosted in.
  3. Data is sharded across service partitions so no.

more reading:

Upvotes: 3

Related Questions