I've got a similar process.
User uploads a couple of 100+meg flat files, we process them for bulk mail
center codes, postnet barcodes, etc and separate flat files based on the
mail center. The entire result is emailed as a zip package, and an entry in
the web-based archive.
Processing runs 1 to 15 minutes, depending on client connection speed and
size of job.
I leave the process running on the initial thread, sending a "+" sign every
100 rows to indicate progress. Worked fine until WINDOWS 2003 and VS 2003 -
now the process dies EXACTLY 105 seconds into the job. I've researched
Machine.Config, Web.Config etc, etc. (Even posted here - nobody responded)
and I have yet to find the problem.
That's my only concern with your project.
BTW, we put a message at the top, just as processing starts:
"This process will continue to completion, even if you close the browser"
That helps... You can monitor Response.IsClientConnected to see if the
escape (stop) your page, or navigate out. Then you can kill the process.
G.L.
"Lenny" <no****@a.com> wrote in message
news:1h********************@comcast.com...
Hello,
Some pages in ASP.NET application perform very process-intensive tasks
(parsing large flat files, saving data to SQL Server, etc.. ) Some tasks
might take longer to execute than users' expectations. New thread(s) will
be started for these process-intensive tasks, so asp.net process can take
over and send response to the client's browsers.
Does anyone see any issues with this scenario?
How can application inform user when thread is completed or failed after
response was sent to a browser.
Can some kind of client-side object maintain connection with the server
and inform a user of the progress and when thread is completed/failed.
Any other alternatives?
Thank you in advance.
