CODEWITHSUNDEEP
azure-service-fabricservice-fabric-stateful
MattWorkWeb
MattWorkWeb

Reputation: 13

Stateful service service fabric app - remoting, and custom state saving provider

I'm writing a first Azure Service Fabric app applying partitioning to stateful services. I have a few questions:

  1. Can I use remoting instead of HTTP to communicate from my web api to my partitions. The Azure example uses HttpCommunicationListener and I've not been able to see how to use remoting. I would expect remoting would be faster?

  2. Can I persist my state for a given partition using a custom state persistence provider? Will that still be supported by the replication features of service fabric?

  3. Can my stateful service partition save several hundred megabytes of state?

Examples/guidance pointers for above would be greatly appreciated.

Thanks

Upvotes: 1

Views: 70

Answers (1)

LoekD
LoekD

Reputation: 11470

  1. You can use SF remoting within the cluster, to communicate between services and actors. Http access is usually used to communicate to services from outside the cluster. (but you can still use it from within)

  2. Yes, you can do that by implementing custom IStateProviderReplica2 and likely the serializer. But be aware that this is difficult. (Why would you require this?)

  3. Stateful service storage capacity is limited by disk and memory. (calculation example behind the link)

Reliable services are typically partitioned, so the amount you can store is only limited by the number of machines you have in the cluster, and the amount of memory available on those machines.

--- extra info concerning partitioning---

Yes, have a look at this video, the start of it is about how to come up with a partitioning strategy.

The most important downside of 'partition per user' is that the #of partitions cannot be changed without recreating the service. Also, it doesn't scale. And the distribution of data is off balance.

Upvotes: 1

Related Questions