Long running method
I had a page that took a long time to load and since the result
of the processing had nothing to do with the rendering of the page, I
wanted to run the long method asynchronously, since I didn’t need to
wait for it to finish anyways. So I tried the code below, but the
method just never runs. I even tried putting a try catch block
around the entire thing and if an exception was thrown I was writing it
to the application event log, but nothing showed up there. I’m
thinking that this has something to do with the Request life cycle but
I’m not sure, does anyone out there know why my method wouldn’t run?
/// <summary>
/// Summary description for WebForm2.
/// </summary>
public class WebForm2 : System.Web.UI.Page
{
private void Page_Load(object sender, System.EventArgs e)
{
WaitCallback callback = new WaitCallback( MyLongMethod );
ThreadPool.QueueUserWorkItem( callback, Request );
}
private void MyLongMethod(object state)
{
HttpRequest request = state as HttpRequest;
//
// do a bunch of stuff that takes a long time……
//
}
}
Anonymous said,
Wrote on July 21, 2005 @ 7:22 pm
not sure if this affects anything, but you’d probably want to wrap that code inside a “if (!Page.IsPostback) {…}” block, so you can guarantee it’s only executed the first time.
breichelt said,
Wrote on July 21, 2005 @ 8:07 pm
Kirk, this is just some sample code, the actual code had other stuff in it that I removed for clarity and brevity, the other code was irrelevant.
gappleby said,
Wrote on July 21, 2005 @ 9:48 pm
I’d say what’s happening is that the queued workitem never gets a chance to run before the page is finished and has been unloaded.
Without trying it out, I can’t say for sure what’s going on, but as a quick test, try explicitly creating a new thread and kicking it off, instead of adding it to the threadpool. There’s more liklihood that the thread will at least start up before your page finishes.
If it _does_ start up, then you at least know why this method fails, if not the right way to do it
Anonymous said,
Wrote on July 21, 2005 @ 10:47 pm
Geoff is right. The thread inside of Page_Load will queue the work item for processing, then run off and finish rendering the page.
When the ASP.NET runtime sees the request has finished processing, then all bets are off on any state related to the request. That includes Request, Response, and any other property on HttpContext.
Anonymous said,
Wrote on July 22, 2005 @ 6:52 am
I think the safest approach would be to extract everything you need from the request and pass the extracted data to the thing you add to the thread pool.
I believe there is always a risk that the request will end before you access it.
breichelt said,
Wrote on July 22, 2005 @ 7:58 am
Geoff, I also tried explicitly creating a new thread, but I got the same result. I think Scott is correct in his assertion, so I’m going to try Thomas’s suggestion, its a pain in the to grab everything that I want from the Request, but such is life…….
btompkins said,
Wrote on July 22, 2005 @ 8:05 am
I am actually just getting into this this week… have you read this? It’s an oldie, but goodie.
http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx?print=true
breichelt said,
Wrote on July 24, 2005 @ 8:17 am
So, I found the problem, the issue was that I was calling into an api that used the HttpContext.Current, not just the Request object that I was passing in, and by the time came to call HttpContext.Current, I was getting a NullReferenceException thrown because there was no HttpContext, like Scott mentioned.
However, I fixed the problem by discovering why the method was taking a long time (6 minutes) in the first place, but I’ll post that as another entry. But now I dont need to run the method asynchronously, so its a non issue, thanks for the suggestions.
Anonymous said,
Wrote on July 31, 2005 @ 10:13 pm
It was taking 50 seconds to connect to MySql 4.1.x from my windows 2003 machine, heres what fixed it.