Abort WebMethod Thread on server side

Question

I have a web method in an ASP.NET site that could run long and consume a lot of CPU capacity. It is also possible that, before a request is returned, the user could fire a new request with other or more parameters from the site. On the client side a do an abort:

if (xhrConfigurate != null) {
   xhrConfigurate.abort();
}

Of course, abort will not stop the calculations on the server. I tought, this is ok, the server will do what it have to do, but will not return the results of the old requests. But it seems that in some cases, the server has troubles to handle all requests in a timely matter. That is why I also want to kill the old requests when a user launches a new one. I have found some solutions with scriptmanager, but would like to avoid using that.

As the webmethod itself is a asynchronous thread, can't I get an instance of this thread, store it in some dictionary where I can abort the old not finished requests for a user and remove a request when it is finished?

<WebMethod> Public Shared Function myRequest(ByVal params As String) As String
   'Get the dictionary with requests
   'Test the dictionary on old unfinsihed request for the user, if there is one: abort
   'Add this request to the dictionary

   'Do work...

   'If work finsihed: remove this request from dictionary
   Return result
End Sub

score 0 · Answer 1 · edited May 23 '17 at 10:31

If I understand correctly, you want to have some global variable dictionary with requests queue, so that any web method execution would share same dictionary?

Using global variable is tricky thing, IIS application pool may restart anytime. Somewhere I read, it's recycling automatically every 24 or 29 hours on IIS. So global variable values might be lost.

Thread related to the problem: What exactly is Appdomain recycling

I have ASP WebApi service, and I have similar long running tasks. I host ASP application in console app (host) (no IIS!), and I use ObservableCollection variable to store requests in AppDomain.

Then each requests thread can access that collection safely (if I am not mistaken).

I'm not worried about the recycling. If that should happen during the application should restart with all the sessions, caching,... That hasn't been a problem in the past. — CyclingFreak, Sep 03 '13 at 08:50

score 0 · Answer 2 · answered Sep 03 '13 at 09:58

In general, it is a bad idea to run a long-running process inside of ASP.NET. Instead, you should create a separate server process, and your ASP.NET code should queue a request to that process.

Your server could return a unique value back to ASP.NET, which could then send that value back to the web page. When the user makes a request, you would pass that value to ASP.NET, which would pass it to the service. The service could determine whether there is already a request running with that unique value and, if there is, the service could abort that thread.

Abort WebMethod Thread on server side

2 Answers2