locked
Spawning a thread from an ASP.NET Request RRS feed

  • Question

  • My App service runs under IIS and ASP.Net

    when a request comes in, I use the main request thread to do most of the work.  There are some tasks (like logging messages to a database), however, I'd like to push to the background using a Fire and Forget approach.

    I'm concerned that if the Main Request Thread (Thread A) places a task in the thread pool (via QueueUserWorkItem), that this spawned thread (Thread B) may fail to execute or get aborted when the main request thread (Thread A) completes. 

    Is it possible to spawn the logging work on a background thread that processes even if the originating thread is complete?

    Tuesday, February 5, 2013 2:27 AM

Answers

  • Is it possible to spawn the logging work on a background thread that processes even if the originating thread is complete? 

    Yes. As far as .NET and the CLR are concerned, the ThreadPool threads are not "owned" or tied to the requesting thread in any way.  As such, Thread B's lifetime is unrelated to Thread A in your scenario.

    Firing off a "fire and forget" method should be safe, for the most part.  Given that you're running within an IIS environment, the app pool can effect this (as Ken mentioned).  This is not the same issue you're bringing up - more that the entire runtime environment (including the ThreadPool itself) could go away.

    If the "logging" is a critical feature, this may be an issue.  If missing a log (very rarely) is okay, then just pushing it off onto the ThreadPool would be very appropriate.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, February 13, 2013 5:23 PM
    Moderator

All replies

  • I am not sure that will work.  Message Queuing (MSMQ) is the only way you can be sure your message gets to where it is suppose to go.  Your app pool for the website could recycle killing your thread before it is run.
    Saturday, February 9, 2013 4:50 PM
  • Is it possible to spawn the logging work on a background thread that processes even if the originating thread is complete? 

    Yes. As far as .NET and the CLR are concerned, the ThreadPool threads are not "owned" or tied to the requesting thread in any way.  As such, Thread B's lifetime is unrelated to Thread A in your scenario.

    Firing off a "fire and forget" method should be safe, for the most part.  Given that you're running within an IIS environment, the app pool can effect this (as Ken mentioned).  This is not the same issue you're bringing up - more that the entire runtime environment (including the ThreadPool itself) could go away.

    If the "logging" is a critical feature, this may be an issue.  If missing a log (very rarely) is okay, then just pushing it off onto the ThreadPool would be very appropriate.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, February 13, 2013 5:23 PM
    Moderator
  • You might accomplish the same performance without Fire&Forget using APM,

    when an IIS thread processing an APM request (IAsyncHttpHandler) it free the iis managed thread handling the initial request,

    this is very useful if you need to continue with I/O operation for example DB/webservice/FileIO and so on. there was a session on that in Build

     

    Tuesday, March 5, 2013 5:01 PM