I've got my own Queue Class that I instantiate from the global.asax file. From my different asp pages, I add things to the queue, and then check their progress.

It seems that this queue class is being aborted and then of course, throws the exception:

System.Threading.ThreadAbortException: Thread was being aborted.

If I want to maintain a class through out the running of the asp.net server, how can I do it. It seems I can not depend on the thread I create to keep running.

any ideas on how to do this? Is it normal that the thread will be killed like it is?

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

Well, a queue class sounds like the right thing to keep things throughout the lifetime of the ASP.NET application. But, I'm not quite sure where ThreadAbortException comes into play. Where/How are you seeing this exception? How is it adversly affecting your code? How does a Queue object you're maintaining pertain to "on the thread I create to keep running"? A queue != a Thread, so I'm confused on what you're trying to accomplish. More info would help :)

-Brock

---

DevelopMentor
http://staff.develop.com/ballen

As an additional point to perhaps help you explain what's really happening, the ThreadAbortException is commonly seen in ASP.NET when a request does a Response.End() or a Server.Transfer(). Perhaps those are in your code somewhere and those are your real problems?

BTW, even though you see a ThreadAbortException, it doesn't necessarily mean the Thread is being terminated. ASP.NET is just using this type of exception to implement the Response.End().

-Brock

---

DevelopMentor
http://staff.develop.com/ballen

To the best of my knowledge, I am not throwing a threadabortexception.

Adding a little background to this, I am actually using a WorkQueue project from "The Code Project" called Work Queue Based Multi-threading by Richard Schneider. I instantiate a workqueue from my global.asax and from other asp pages, I add workitem's to the workqueue. Workitems are basically classes with a Perform method. The workqueue limites the number of workitems that can be processed at a time. (I have this set to 1).

Back to my problem. I get the workqueue loaded and running on my local IIS 5 server. I then go make dinner, and it seems that after 10 or 20 minutes (always different) this ThreadAbortException is thrown. Sometimes, it even finishes all the workitems with no errors. So, basically, I don't think the problem can be related to my response.end problems because those only happen when I view graphs. (the author of that class asked me to put a full example together for him so he can fix the problem. He doesn't see it in vs2003).

At any rate, I hope this helps. and again, thanks for your help and thoughts on this. It really helps me a lot to understand what is going on.

-Peter

PS: an aside note. I have a nunit test I run that basically does the same thing in vs2003 (same c# code) and it never throws an exception. This makes me feel there is something in the asp.net or iis causing it but I really don't know.

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

Hmm, ok, so after more info it sounds like it's quite involved. That makes it much more difficult to debug over the forums :)

One other scenario where you see the ThreadAbortException is when the AppDomain for your application shutting down. So perhaps you queue lots of work into this workqueue... it's working along... then since you've not made a request into ASP.NET, based upon the inactivity configuration it's decided to shutdown. Now, since you're running on IIS5 this inactivity is configured in machine.config in the <processModel> element. The default value for that is idleTimeout="Infinite", so maybe this isn't your problem....

Oh wait, you say it only happens when you view graphs? So this means you are making requests into your application while you're making dinner (how do you do that? :P Oh, I see... automated tests :))...

Well, so if you are making requests into the site then you see the ThreadAbortException then I'm thinking it's a Response.End() or Server.Transfer() that's happening. You still didn't say where you see this exception... Do you see it in the browser? Or do you see it because you're logging exceptions in Application_Error?

-Brock

---

DevelopMentor
http://staff.develop.com/ballen

Actually, it happens when there are no requests coming in. (while I'm making dinner). The way I know it is happening is that in the workqueue's function that executes the Perform of my workitem, there is a try catch loop. in that loop, I catch the exception and log it to a disk file.

Is there anyway to tell who threw this exception? below is the code that catches the exception and logs it. (my code I stuck here)

try
{
workItem.Perform();
}
catch (Exception e)
{
workItem.FailedException = e;
workItem.State = WorkItemState.Failing;

// PGK
lock (threadPool)
{
try
{
StreamWriter output;
output = new System.IO.StreamWriter("C:\\temp\\_HillViewer.log", true);
string str = DateTime.Now + " " + e.ToString();
output.WriteLine(str);
output.Close();
}
catch (Exception)
{
throw;
}


}

my _HillViewer.log has the following:

2/17/2005 5:25:43 PM System.Threading.ThreadAbortException: Thread was being aborted.
at System.Threading.Thread.Sleep(Int32 millisecondsTimeout)
at HeartBeatWorkItem.Perform() in c:\WebSites\HillFinder\code\LocalLib\HeartBeatWorkItem.cs:line 46
at BlackHen.Threading.WorkThread.DoWork(IWorkItem workItem) in c:\WebSites\HillFinder\code\LocalLib\WorkQueueLibrary\WorkThreadPool.cs:line 477

Line 46 of HeartBeatWorkItem is a simple sleep (in this case for 15 seconds)

Thread.Sleep(sleepMS);

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

It could be a session time-out that cause your problem. When a user requests a page from a The Session timeout determine when the application ends. When the last session ends, IIS ends the application. The default time-out is 20 minutes. That means that 20 minutes after a user makes his or her last request to an application, the user?s session ends. When there are no more sessions, the application ends. The time-out of the session could maybe abort your thread.

Remember that you should be very careful when you use threads within web applications. If put the current thread for the request into sleep, it will block the thread. A Web application has a limit of numbers of thread and each user that request a site will use a thread from a thread pool. If all threads are sleeping and there is not thread left in the pool, other users that request a page will need to wait until a thread is released (after a page has been processed). Maybe your solution is not a good solution for a web application? If the example you told about is coming from a Windows Forms application, than reconsider if you have really used that right solution to solve your problem in a web application.

---

/Fredrik Norm?n NSQUARED2
Microsoft MVP, MCSD, MCAD, MCT

Cornerstone

My Blog, ASP.Net 2.0 etc

And just to add to Fredrik's note, since it's easy to flood the ASP.NET thread pool with asychronous requests (like the ones from your queue) or from any other async operation in .NET, you might consider creating your own thread pool. Mike Woodring has one available on his website.

As for capturing more information from the exception being thrown, you actually have all the info you need rigth there. The call stack shows what's going on. Perform() is getting called and whoever it's wired up to is calling Sleep(). Is that in there for testing or for something else? If it's not in there for testing, then that's probabaly not the best thing to do since it's eating up a thread from the pool (as Fredrik's explained). If the Thread is sleeping long enough, I wonder if ASP.NET is assuming it's deadlocked and killing the thread via the Thread.Abort()?

-Brock

---

DevelopMentor
http://staff.develop.com/ballen

the heartbeatworkitem thread that is performing the sleep is strickly for testing to try to solve this problem. If I understand correctly, Fredrik is saying that after 20 minutes (or so) of inactivity, the application thread will always get this exception. Assuming this is true, I am thinking I need to figure out how to move the work do a different process out of the asp app domain.

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

Umm, I'm not sure if that's exactly the problem. But there certainly is something going on. Try using the alternate ThreadPool link I sent you. It's quite easy to use. Try it and see if it has the same problem. I'm thinking it's something to do with the fact you're using threads from the ASP.NET thread pool rather than your own. I've build a few different websites that have incorporated this other ThreadPool and it works quite well.

-Brock

---

DevelopMentor
http://staff.develop.com/ballen

The author did track this problem down and solved it by changing ctx.Response.End(); to ctx.ApplicationInstance.CompleteRequest(); per a microsoft msdn suggestion.

http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;312629

I'm sure this doesn't have anything to do with my other threadabort problem so I'm off taking Brock's suggestion at the moment and going to try and make another thread pool. (and Frekrik's suggestion of making sure I don't consume too many threads)

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

After further testing, it seems Fredrik is correct in his 20 minute thing. I made a simple asp.net app in which I start a thread from the global.asax with a sleep forever logging every 15 seconds to a file.

I poked the app every 15 minutes for an hour and it never died. After I stopped poking it, it died exactly 20 minutes after my last poke. When I started the app and didn't poke it at all, it dies after exactly 20 minutes.

Now, to try the custom threadpool and see if that doesn't get killed.

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

Are you running under Windows 2003 and IIS6? If so, then that's why you're seeing the exception. After 20 minutes of inactivity to release resources, IIS shuts down your ASP.NET application. This is a setting in IIS's admin tool. Go find the AppPool for your application (or create a dedicated AppPool) and check out the first option on the Performance Tab.

The custom ThreadPool I cited won't fare any better if this is your problem. If you need code to run past the lifetime of your ASP.NET application, then a NT service might be the way to go. Or you can look into the Windows Scheduler.

HTH

-Brock

---

DevelopMentor
http://staff.develop.com/ballen

OK, that is a big help. I'm actually running all on XP with either the developement server built into vs2005 (not sure what that is) as well as running iis 5 which is part of XP when I installed it.

Since my repository for the work is all sqlserver, it's easy for me to move the work outside the iis server. (OK, maybe not easy, but very straight forward). This has been very educational for me.

Thanks for all the help and thoughts.

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET

So, being a dilligent engineer type, I am going through my old code from beta 1 and testing it all in beta 2.  I want to verify that my "pulsing" of my asp.net app is still keeping it from timing out so first thing I do is verify it fails like it used to so I can maek sure my fix really fixes something.

I can't get the app to timeout anymore.  I believe we concluded that the 20 minutes of inactivity was causing a session timeout and clobbering my application variables I declared in global.asax.  Now, in Beta II, I let my app run un touched by human hands for over 60 minutes and no timeout.

Did the session time out change from beta 1 to beta 2?

I hate to complain about something not failing but I am a little stymied.

Thanks again for all the help on this before and what I thought was my solution.

-Peter

---

Peter Kellner
http://73rdstreet.com and blogging at
http://PeterKellner.net
MVP, ASP.NET