Do Not Adjust Your Browser

subtext, code 0 comments suggest edit

This blog is experiencing technical difficulties. Do not adjust your browser.

Hi there. If you’ve tried to visit this blog recently you might have noticed it’s been down a lot in the last two days. My apologies for that, but hopefully you found what you needed via various online web caches.

I’ve been dogfooding the latest version of Subtext and as CodingHorror points out, dogfood tastes bad.

I’ve done a lot of testing on my local box, but there are a class of bugs that I’m only going to find on a high traffic real site, and boy have I found them!

Some of them might be peculiar to my specific data or environment, but others were due to assumptions I made that were wrong. For example, if you use ThreadPool.QueueUserWorkItem to launch a task, and that task throws an unhandled exception, that can bring your entire App Domain down. Keep that in mind if you think to use that method for a fire-and-forget style task.

In any case, the point of this post is to say that we’re not going to release the next version of Subtext until it’s rock solid. My blog going down occasionally is the cost I’m incurring in order to make sure the next version of Subtext is a beast that won’t quit.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

7 responses

  1. Avatar for Paco
    Paco January 12th, 2010

    Another issue of using the threadpool is that it's possible to exhaust all the threads. When this technique is used to send an email, and the mailserver is down, and the timeout is 60 seconds, the whole webserver is down (or sleeping for a too long time) when a all threads are waiting for the timeout to send an email.

  2. Avatar for Darren Kopp
    Darren Kopp January 12th, 2010

    Why not use

    Action forget = () => DoSomething();
    forget.BeginInvoke(p => {
    try {
    forget.EndInvoke(p);
    } catch (Exception ex) {
    // something went bad, log?
    }
    }

    don't know if that does threadpool or not, but at least you could catch the exception.

  3. Avatar for Mat Roberts
    Mat Roberts January 12th, 2010

    A couple of post ago you published this:
    This is a temporary post that was not deleted. Please delete this manually. (ee860299-38dd-4af0-a65e-d1a8926b49c1 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
    In google reader it says that 5 people liked that post.
    Your a lucky guy to have so many readers that publishing a GUID can get such a positive reaction.
    Good luck with your subtext work.
    Cheers
    Mat

  4. Avatar for Brian
    Brian January 12th, 2010

    Like Paco said, the ThreadPool threads in your asp.NET application are used by the asp.NET worker process threads. I believe you have 32 on a default configuration. The more you use to run 'background work' the less simultaneous requests you can handle, right up to 0 requests if you queue up too much background work.

  5. Avatar for NC
    NC January 12th, 2010

    OMG Stop talking about Coding Horror, Jeff is a fucking retard. Why do people even follow him.

  6. Avatar for Thanigainathan
    Thanigainathan January 12th, 2010

    The post very helpful

  7. Avatar for Nigel Holland
    Nigel Holland January 12th, 2010

    Killing the app domain has nothing to do with the thread coming from the pool, if an unhandled exception passes a thread boundary, the thread will stop with a non zero status causing the host process to stop with a non zero status.
    I recommend Sambuca to get rid of the taste of dog food :)