Does service fabric create singleton instance for

Question

Say I created a stateful service fabric service with 5 partitions on a 5 node cluster. I see that each node gets 1 partition per node. When I debug the service in VS, I notice that service fabric is creating exactly 5 instances of the stateful service [essentially 1 static instance per partition] across all 5 partitions. No mater how many calls the clients make, there are only 5 instances of this class to serve requests from. Are the following statements true?

• Any class level member variables in the stateful service are essentially static [since it resolves to a singleton instance on that partition] and therefore require "lock" semantics when updating?

• Since the client always resolves to a the "same" instance of the class all the time for a given partition, the client can re-use the "proxy" instance?

• How does this "singleton" model of stateful service creation affect performance and scalability when lot of clients call the same service instance hundreds of times a second. [under heavy load] I understand that there is a setting when configuring the V2 remoting listener where we can specify "MaxConcurrentCalls" via "FabricTransportRemotingListenerSettings".

Answer 1

There are some misconceptions here:

Instances are Different than processes, when you say that you can see the instances on Visual Studio, what you actually seeing are processes. There are cases where you can have multiple instances in a single process, and visual studio will show you only one, but there is actually 5(in your case). This is defined by the SF Hosting Model configuration, where you define how it should behave, I have answered related questions here #1 and here #2

The other is, Stateless services have Instances, Stateful services have Partitions & Replicas. Based on that, what you see are not instances, they are Primary replicas(And maybe secondary if you define the replication > 1). See more details in the docs here

Given the previous details, when you do a partitioning of a service, depending on which hosting model you use, it can create multiple Replicas on the same process or one per process.

There is only one catch on all this, the number of replicas from same partition is limited by 1 per node, to have more info about this, take a look at this issue on github

Regarding your questions:

No mater how many calls the clients make, there are only 5 instances of this class to serve requests from. Are the following statements true?

No!

If you are talking about request to an ASP.NET endpoint or remoting calls, this does not affect instance count, instances are defined by the SF configurations and client requests won't affect it, it will be split among the available instances depending how you balance these requests. The only way these requests will affect the instance count is when you define auto-scaling in the service.

When a new instance\replica of your Stateless\Stateful service is started (Within or Outside the same process), a new object is created. A call to these services might always go to the same object, but not will always be the case, because the SF might re-balance your service and kill these instances to create new ones somewhere else, or in case of failures.

There is also the case for stateful services, the calls only go to the primary replicas, unless you specify a read to a secondary one. In case a secondary is promoted to primary, new calls won't be redirected to the former primary replica. What is quite common to happen or cluster maintenance and application updates.

Any class level member variables in the stateful service are essentially static [since it resolves to a singleton instance on that partition] and therefore require "lock" semantics when updating?

If you use shared hosting model, all static objects will be shared with any instance within the same process.

Since the client always resolves to a the "same" instance of the class all the time for a given partition, the client can re-use the "proxy" instance?

Based on previous answer, yes, any singleton class, will be shared. .

How does this "singleton" model of stateful service creation affect performance and scalability when lot of clients call the same service instance hundreds of times a second. [under heavy load] I understand that there is a setting when configuring the V2 remoting listener where we can specify "MaxConcurrentCalls" via "FabricTransportRemotingListenerSettings".

I didn't understand properly the problem here, maybe the previous answers might clear it for your, if not, leave comments below and I will update it.

Answer 2

Confirmation from Microsoft. Service fabric indeed creates 1 [ONE] instance of a "reliable service" per partition. This "singleton" instance will service all client remoting/http calls. If a failover happens to a replica, a new instance will be created.