views:

512

answers:

4

Hi everyone, what would happen if I spin off a thread to execute a long-running process right before the ASP.NET page lifecycle completes? Will the ASP.NET runtime kill the thread? Can this lead to undefined behaviour?

Here's a sample of the code, which spins the background thread in the Page_Load event. Is this a safe thing to do?

protected void Page_Load(object sender, EventArgs e)
{
    Thread newThread = new Thread(new ThreadStart(SomeLongRunningMethod));
    newThread.IsBackground = true;
    newThread.Start();
}

private void SomeLongRunningMethod()
{
    // some long running process goes here...
}
+1  A: 

I have done some experimenting with the same type of code doing some time consuming logging in a separate thread. It seems to work well, but I haven't tested it in a production enviroment.

The only difference between your code and mine is that I used the thread pool instead of setting up a new thread.

You will probably make copies of any request data and other page information to avoid them being disposed but apart from that I think this should work well.

Rune Grimstad
well that's precisely my concern. I've done something like this and it *seems* to work fine, but you never know... ;) that's why I'd like to find out what the "official" ASP.NET behaviour is.
cruizer
Did you try what happens when session ends ? I wonder this case especially.
Canavar
I think the official recommendation is not to do it. Instead you should pass the job to a service or some other remote process that you are guaranteed will live long enough
Rune Grimstad
I will check if my code is used in production anywhere and try to check what happens if the session ends. It should be quite easy to check I guess.
Rune Grimstad
I did some checking and we haven't used it in production yet. I'll try to setup a test to see what happens when the session times out.
Rune Grimstad
A: 

Be aware of the IIS worker recycling settings as these could still affect your thread after it has been started. Make sure you catch any exceptions and log them.

ck
+1  A: 

I've done som video converting / processing with ffmpeg on movies uploaded by users on a web form and it worked perfect, even if the thread took several hours to complete! It's very important to keep in mind that it's hard to find out the status of the thread, so logging and error handling is extreamly important.

bang
A: 

A colleague recently did this for some data exports. The client would log into a control panel (web based) and then hit some buttons and what not and then a file would be FTP'd off to some mystical server.

The front end was done using ASP AJAX and like @bang says, the thread executes well but it's an absolute shit to keep track of.

AJAX was used to update a progress bar and status line in the UI which was nice in theory and while the data set was only a couple of hundred rows. But as soon as we started working with the real dataset (millions of rows) the entire UI kept bombing out with timeout errors. At this point you lose touch with the background thread...

Is it still running? Has the export finished? What will happen if I refresh the page and press the button again? Will the fulfilment house send two products to the folks?

It's a bit of a nightmare. He's currently re-writing it to run as a console app scheduled with the windows task scheduler wired up to a jobs table that contains details of the exports that need doing.

If this seems a bit shonkey, you could always write your long-running process with a bit of a socket server and have your aspx code-behind communicate with that.

Greg B