REST-Call with async server implementation-CodePudding

In my application I have a server which provides a REST-Api where my UI can communicate with.

Now I have to start a long running Process on the Server but I want the client not to wait for the response of the server.

I know I could just fire and forget the Post-Call and not await the response but I need to know at the client that the Process on the server was startet correctly.

So I thought about the following:

[HttpPost]
[Route("startscan")]
public HttpResponseMessage StartScan()
{
  Task.Factory.StartNew( () =>
  { 
    //Do long running things here 
  }); 
  return Request.CreateResponse(HttpStatusCode.OK);
}

So my question now is: Will the task I started be executed to it's end? Background of the question is, that as far as I knwo a controller-instance is created for each call to it. So will the instance of the controller be terminated when the requested finished or will the Task I started run to it's end. The task can take up to 10 minutes or longer sometimes.

CodePudding user response：

A simple approach would be to just use an asynchronous method without awaiting the Task result like so:

[HttpPost]
[Route("startscan")]
public async HttpResponseMessage StartScan()
{
  DoLongRunningThings();
  return Request.CreateResponse(HttpStatusCode.OK);
}

public async Task DoLongRunningThings()
{
  // Do Stuff here
}

However, if you Processing is more complex and requires more resilience you should look into how to use background jobs. Here is a good collection of what you can use: https://stackoverflow.com/a/36098218/16154479

CodePudding user response：

Will the task I started be executed to it's end?

Probably yes, but also possibly no. Sometimes it won't be executed completely. This is the result of misusing an ASP.NET app (which handles HTTP requests) as a background service (which runs outside of a request context).

There is a best practice that avoids possibly-partial execution: a distributed architecture (as I describe on my blog). The idea is that your controller enqueues a message describing the work to be done into a durable queue and then returns. Then there's a separate background service that reads from the queue and does the actual work.