Azure Service Fabric Specify Service/Application Startup Dependency

1
votes

To ask briefly, is there a way to specify Service/Application Startup dependency in Azure Service Fabric?

I have two services, say S1 and S2. S2 depends on S1, and must be started after S1 starts. Currently S1 and S2 are under different applications packages. I can also put them into one application package if necessary.

It works if I start S1 first, then S2 during deployment. However, seems that Service Fabric has some maintenance work, during which services get restarted. Now the problem is that the order of starting S1 and S2 is not guaranteed, which causes S2 to fail to read some configurations during initialization. S2 fails silently but keeps running.

In Service Fabric there's way to specify SetupEntryPoint", however in this case S1 itself has an "SetupEntryPoint", besides I feel it is not proper to put a long running service under "SetupEntryPoint".

I'm also thinking about making S2 stop when it fails to read configurations from S1, in that case Service Fabric will keep trying restarting S2 until S1 gets started.

But is there any way to guarantee S2 starts after S1 through Service Fabric config?

1
azure-service-fabric
I added a logic in S2 to detect the existence of S1 process and delay the initialization, which seemed to work – user2188649

1 Answers

1
votes

I also faced the same problem. I don't think it is possible via the Service Fabric config alone.

What in the end I come up with the solution is that I redesign the service in the way that it won't completely startup unless the dependent service is up. In my case, my service A depends on service B. If service A boots first, it'll fire a message to the message bus, and wait for service B to reply. If service B is already started, then it'll reply directly. If service B is not yet started, once it started it'll reply. Then when service A gets the reply, it'll just continue with it's startup. That way it'll be always be able to really finish starting.

Another easier way is that if service B is down, just throw an exception in Service A. Service Fabric will try to start the application in another node, and hopefully by then service B is up. The down side is that the first initial boot will be painfully slow (as it'll keeps retrying until the correct order shows up) and also you'll be seeing a lot of error (but eventually will go away when all services finished startup)