views:

194

answers:

5

Hello,

I know we need a better solution but we need to get this done this way for right now. We have a long import process that's fired when you click start import button on a aspx web page. It takes a long time..sometimes several hours. I changed the timeout and that's fine but I keep getting a connection server reset error after about an hour. I'm thinking it's the asp.net lifecycle and I'd like to know if there are settings in IIS I can change to make this lifecycle last longer.

A: 

You can try running the process in a new thread. This means that the page will start the task and then finish the page's processing but the separate thread will still run in the background. You wont be able to have any visual feedback though so you may want to log progress to a database and display that in a separate page instead.

You can also try running this as an ajax call instead of a postback which has different limitations...

Since you recognize this is not the way to do this I wont list alternatives. Im sure you know what they are :)

Ariel
A: 

Extending the timeout is definitely not the way to do it. Response times should be kept to an absolute minimum. If at all possible, I would try to shift this long-running task out of the ASP.NET application entirely and have it run as a separate process.

After that it's up to you how you want to proceed. You might want the process to dump its results into a file that the ASP application can poll for, either via AJAX or having the user hit F5.

Quick Joe Smith
A: 

If it's taking hours I would suggest a separate thread for this and perhaps email a notification when it is ready to download the result from the server (i.e. send a link to the finished result)

Or if it is important to have a UI in the client's browser (if they are going to be hanging around for n hours) then you could have a WebMethod which is called from the client (JavaScript) using SetInterval to periodically check if its done.

Mister Cook
Is the separate thread also affected by the lifecycle because I've put it in a separate thread and it still stops about 45 minutes into the process.
A background thread shouldn't be affected by the page life cycle, but it might be affected by an asp.net recycle (see my new post)
Mister Cook
A: 

One other point to consider which might explain the behaviour is that the aspnet_wp.exe recycles if too much memory is being consumed (do not confuse this with the page life cycle)

If your long process is taking up too much memory ASP.NET will launch a new process and reassign all existing request. I would suggest checking for this. You can do this by looking in task manager at the aspnet_wp and checking the memory size being used - if the size suddnely goes back down it has recycled.

You can change the memory limit in machine.config:

  <system.web>
    <processModel autoConfig="true"/>

Use memoryLimit to specify the maximum allowed memory size, as a percentage of total system memory that the worker process can consume before ASP.NET launches a new process and reassigns existing requests. (The default is 60)

<system.web>
    <processModel autoConfig="true" memoryLimit="10"/>

If this is what is causing a problem for you, the only solution might be to have a separate process for your long operation. You will need to setup IIS accordingly to allow your other EXE the relevant permissions.

Mister Cook
+1  A: 

You should almost certainly do the long-running work in a separate process (not just a separate thread).

Write a standalone program to do the import. Have it set a flag somewhere (a column in a database, for example) when it's done, and put lines into a logfile or database table to show progress.

That way your page just gets the job started. Afterwards, it can self-refreshe once every few minutes, until the 'completed' flag is set. You can display the log table if you want to be sure it's still running and hasn't died.

This is pretty straightforward stuff, but if you need code examples they can be supplied.

egrunin
I would go further and make it an NT Service. Database as you suggest for communication with web server, is fine, or use WCF.
Hightechrider
If it's a process that's run infrequently, and exits when done, I'm not sure what the advantage of a Service would be.
egrunin