0

Currently I am launching a long running thread in Startup.Auth.cs

which is where ConfigureAuth is called by the ASP.NET app when the application is starting. Currently I am launching my thread here with the following:

try {
  LaunchListenThread();
}
catch (ThreadAbortException e) {
     Console.WriteLine("Thread - caught ThreadAbortException - resetting.");
     Console.WriteLine("Exception message: {0}", e.Message);
     Thread.ResetAbort();
     LaunchListenThread();
}

The function LaunchListenThread() essentially just launches the thread that is declared in Startup.Auth.cs

The thread is declared as

private readonly ThreadStart nThread = new ThreadStart(NetComms.StartListening);

My primary concern here is catching a ThreadAbortException, which for example, if I throw in StartListening, it does not appear to be caught by the previously mentioned Catch block.

What I am wondering is a more standard or accepted way of launching a long-running thread like this in IIS, particularly in which I am able to catch a ThreadAbortException

I have tested so far by doing the following:

System.Threading.Thread.CurrentThread.Abort();
catch(ThreadAbortException te) {
    throw te;
}

The error is thrown, but it is lost thereafter.

Please let me know if any additional information would be helpful.

pay
  • 366
  • 3
  • 18
  • 1
    Since appdomains can (and will) be recycled, I make it a habit not to run long-running processes in ASP.Net. I usually call an external stand alone service through WCF that does the work. – atlaste Mar 22 '16 at 14:25
  • I have IIS configured quite well to not recycle my thread, and I have allowed the thread to idle for days-weeks and it still remains active. My primary concern right now appears to be rogue ThreadAbortExceptions. I am not sure this has actually happening before, it is more something I am worried about not being able to catch properly. – pay Mar 22 '16 at 14:28
  • Still I wouldn't recommend it; f.ex. you might end up with multiple threads as a result of multiple app domains, issues with web farms, etc. ASP.NET is simply not designed to do things like this. Anyways, if you're not convinced, these exceptions are usually the result of things like `Request.End()` and one of the ways that ASP.Net works with requests. Either way, `ThreadAbortException`'s can be aborted. e.g. `te.ResetAbort()`. The consequences of such actions are yours of course... – atlaste Mar 22 '16 at 14:34
  • See also: http://stackoverflow.com/questions/536681/can-i-use-threads-to-carry-out-long-running-jobs-on-iis?rq=1 – atlaste Mar 22 '16 at 14:35
  • Ok, thanks for the replies. I probably should have noted that this is a strictly non-internet intranet application that will handle very few users, and very little variance in how the app runs. – pay Mar 22 '16 at 15:45

1 Answers1

1

I recommend you to use a tool like hangfire.io.

Here is why it is dangerous to run Recurring or Background Tasks In ASP.NET

and here are some alternatives: How to run Background Tasks in ASP.NET

rphv
  • 5,409
  • 3
  • 29
  • 47
Yehia Amer
  • 608
  • 6
  • 11
  • Thanks, I'm looking into hangfire now... I am a little curious though, people mostly refer to 'background tasks', whereas what I want to run is more of a permanent background listener... It is a thread always waiting for incoming TCP connections to process log data. Is hangfire suitable for something like this as well? – pay Mar 22 '16 at 18:23
  • @user1438893 Sure it is called a "Fire-and-forget tasks" in hangfire :) – Yehia Amer Mar 22 '16 at 18:27
  • It was so easy to set that up it almost feels like cheating! What I'm unsure of now though is error handling. The function I passed Hangfire is `StartListening()`, but the entire class that function is in contains quite a lot of network and database operations. Is there documentation for Hangfire specifically related to if my code throws exceptions or things like that? I should note that as far as I know there are no execution paths in my code where an UNCAUGHT exception would happen. I'm just wondering how that would work. – pay Mar 22 '16 at 18:45
  • @user1438893 yes, there documentation is one of the best out there. Take a look here: http://docs.hangfire.io/en/latest/background-processing/dealing-with-exceptions.html – Yehia Amer Mar 22 '16 at 18:52
  • Impressive! I'm throwing unhandled exceptions around and Hangfire seems to handle them gracefully. Thanks for the suggestion! – pay Mar 22 '16 at 19:17
  • Well one more question... Is there a preferred location to launch a task with Hangfire? As in inside `ConfigureAuth` or perhaps inside `Application_Start`? I am currently following the example here: http://docs.hangfire.io/en/latest/background-processing/processing-jobs-in-web-app.html. Although they don't actually queue a task here, I am also Enqueuing the task inside `Configuration` – pay Mar 22 '16 at 19:21
  • @user1438893 take a look at the documentation specially "deployment to production" section and "best practices" section – Yehia Amer Mar 22 '16 at 19:27
  • Some rather odd behaviour, in that Hangfire tries to run the function I pass it 2-3 times. I am not exactly sure why it would do this as there is only 1 call to `BackgroundJob.Enqueue(()` and it is only hit once when the application is starting. I'll look around for why this might be happening, unless you have any insight on this? – pay Mar 22 '16 at 20:01