CODEWITHSUNDEEP
c#azureazure-service-fabric
INNVTV
INNVTV

Reputation: 3367

Best practice for shutting down a StatelessService instance on Service Fabric from within itself

I'm working on a ServiceFabric scenario where I spawn an instance of a Stateless Service in order to run some tasks. I'm using FabricClient.ServiceManager.CreateServiceAsync to create the instance and this works as expected.

Once my tasks are complete I want the service that I spawned to shut its self down so I use FabricClient.ServiceManager.DeleteServiceAsync.

The service shuts down as expected, however my debugger stops in the Program.Main class at this line:

// Prevents this host process from terminating so services keep running.
Thread.Sleep(Timeout.Infinite);

There is no exception, and I am able to hit continue and my application runs as expected after this occurs. But I must be missing a step in order to shut down my service properly. Is there a "Best Practices" way to do this?

I thought about having my service request another service (like a custodian) to handle the shut down, but that seems like too much overhead to me.

My preference would be that the service itself should be able to handle that on it's own, unless of course it turns out to be a bad practice.

UPDATE:

I moved the deletion of the service to a ManagerService to handle shutting it down, but my debugger still stops on Program.Main of the deleted service as it did before. I also added a screenshot (below).

If I hit continue everything keeps running as it should. Is this because the debugger is still attached and doesn't understand that the service is no longer running under fabric? Can this be ignored and released into production?

enter image description here

UPDATE 2

I'm getting a lot of feedback that since I have the debugger running it is expected behavior that it would hiccup once I have no instances of that particular service running on fabric anymore. Since I am getting the same behavior if I delete the service from within itself or from an external service I wanted to get some thoughts on best practices for this scenario...

Ideally having the service clean itself up is best since there are no dependencies to an outside service, it's less complex and there is much less code to write (and less to go wrong).

Surely there is a best practice for doing this outside of having to call FabricClient? Is there a "Shutdown" override of some sort? Does the CancellationToken come into play here?

Upvotes: 0

Views: 1647

Answers (3)

masnider
masnider

Reputation: 2599

The behavior you describe is expected (your debugger if you started it in main is probably sitting on that timeout line the whole time). The lifecycle of the host process is not the same as the lifecycle of the services hosted inside it.

When the host process is empty, Service Fabric waits a bit before shutting it down since service hosts aren't normally empty in production and its trying to avoid the overhead of creating and destroying the process (which would slow down subsequent service creations).

By default Service Fabric checks to see if the process is empty about every minute and then will mark it for closure, then makes a sweep and closes empty processes every 10 minutes or so, so you could see an empty process persist for about 11 minutes if you hit the timing just right.

Upvotes: 3

antar
antar

Reputation: 510

I have seen this happened to me while working debugging the service fabric. Usually, I see this behavior when my debugger is attached for a long time. As long as the service is shut down and you can verify that it does not exist anymore after DeleteServiceAsync is completed, using Service Fabric Explorer site, it should be fine.

Upvotes: 0

Sean Feldman
Sean Feldman

Reputation: 25994

You create your service from the outside. It makes sense to delete the service from the outside as well. Personally, I would send a message to the "custodian" to indicate that service is completed and can be removed.

Upvotes: 0

Related Questions