Do Not Adjust Your Browser

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.

Comments

7 responses

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.

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.

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

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.

NC • January 12th, 2010
OMG Stop talking about Coding Horror, Jeff is a fucking retard. Why do people even follow him.

Thanigainathan • January 12th, 2010
The post very helpful

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 :)