Finish execution of ASP script when client disconnects

  • Thread starter Boris Nikolaevich
  • Start date
B

Boris Nikolaevich

This is backwards of what I usually want--normally if you have a
long-running ASP script, it's a good idea to check to see whether the client
is still connected so you can cancel execution.

However, I have a script that absolutely MUST finish one it's been
started--is there a way to cause the entire script to execute, even if the
client disconnects in the middle of the process? It doesn't matter if the
script returns anything to the client, but once it starts saving values to
the database I need it to finish!

Thanks for your help!
--Boris
 
A

aa

Boris,
I do not know if code execution on the server depends on connection, but if
you have to force termination of the execution upon connection termination,
then it means that by default the code executes to the completion
irrespective the connection
I.e. you do not have to do anything

Andrei
 
B

Boris Nikolaevich

That's what I'd have thought, but I have found very consistently that if I
submit the request and wait for a response (which may be up to two minutes),
the script completes its execution--but if I refresh, close the browser,
move to a different page, etc. etc. the script does not finish.

Apparently starting with IIS 5.0 the ASP engine checks to see whether the
client is still connected before executing a request from the queue. Here's
something I found on MSDN when searching for related topics:

==============================
<snipped from
http://msdn.microsoft.com/library/en-us/dnasp/html/asptips.asp>

Tip 16: Use Response.IsClientConnected Before Embarking on Long Trips

If the user gets impatient, he or she may abandon your ASP page before you
even start executing their request. If he clicks Refresh or moves to a
different page on your server, you will have a new request sitting at the
end of the ASP request queue and a disconnected request sitting in the
middle of the queue. Often this happens when your server is under high load
(so it has a long request queue, with correspondingly high response times)
and this only makes the situation worse. There's no point executing an ASP
page (especially a slow, heavyweight ASP page) if the user is no longer
connected. You can check for this condition by using the
Response.IsClientConnected property. If it returns False, you should call
Response.End and abandon the rest of the page. In fact, IIS 5.0 codifies
this practice—whenever ASP is about to execute a new request, it checks to
see how long the request has been in the queue. If it has been there for
more than 3 seconds, ASP will check to see if the client is still connected
and immediately terminate the request if it's not.
==============================

Obviously this is great for improving performance, but it doesn't help me
any... any more ideas? And BTW, this is a hosted client application where I
don't have control over server settings like AspQueueConnectionTestTime.

Thanks for your response!
 
M

Michael D. Kersey

Boris said:
This is backwards of what I usually want--normally if you have a
long-running ASP script, it's a good idea to check to see whether the client
is still connected so you can cancel execution.
However, I have a script that absolutely MUST finish one it's been
started--is there a way to cause the entire script to execute, even if the
client disconnects in the middle of the process? It doesn't matter if the
script returns anything to the client, but once it starts saving values to
the database I need it to finish!
Thanks for your help!
--Boris

Long-running tasks are not ASP's strength. Here's a alternative and
simple yet powerful approach for handling such tasks that I've suggested
a number of times on these forums. It's essentially a background
batch-processing system that allows submission of "jobs" from an ASP
page. Several advantages
result from separating long-running batch jobs from ASP:
a) greater interactivity for the ASP user,
b) a reduction on the load to IIS,
c) control over the number of concurrently running batch jobs, and
d) the ability to continue/restart jobs if IIS, the database or any
subsystem goes down or if a job fails (e.g., due to program error,
etc.). The result is a much more robust and flexible processing system.

Here are the 3 major pieces of such a system:

1. Job Requestor Page:
Let the ASP page request a job by adding an entry to a "job table" in
the database. The ASP page stores the necessary data (job input
parameters and user information) in the job table. Once the job is
entered into the table, the ASP page merely tells the user his/her job
is queued and exits (or redirects to the Job Monitor ASP page, below).

2. Job Scheduler:
Use a stored procedure, Windows Task Scheduler, SQL Server Agent or a
VBScript script started by the @ (AT) processor to periodically examine
the job table. If no job is currently running and a new job has been
submitted then get the input parameters for the new job from the job
table and start it. Once a job completes, the status of the job should
be marked as "complete" in the job table and a URL for the result (if
required) provided in that same table.

3. Job Monitor:
This is an ASP page that displays the status of jobs and each job's
location in the job queue. The user can display this page to determine
the status of his/her job. Once a job is complete, it's status is marked
as such in the job table along with any resultant URL (a report, a DOC
file, an HTML page or other file). The user can click on that URL to
view the result of his/her batch run.

You can add operator/user functions such as
a. terminate job,
b. put job on temporary hold (cease processing),
c. restart job (in case of system reboot, database shutdown, etc.),
d. allow a variable number of concurrent jobs to run, thus controlling
the background job load.

These require that the code for the various jobs be written in such a
manner that they cooperate with the Job Monitor program.

Good Luck,
Michael D. Kersey
 
M

Michael D. Kersey

Boris said:
Michael,

Of course your suggestion is perfect, and it's one of the first dozen things
I tried--but I quickly ran into a big problem. Since the ASP application
runs on the client's ISP's web server, I don't have the ability to create &
schedule a Windows task. The ISP has also disabled--and refuses to
enable--SQL Server Agent, so I can't schedule (or even start) a SQL Server
job. I don't know of any other way to regularly poll my tables for new jobs
in such a way that the user can continue working while the job is processed
asynchronously. For example, if I execute a stored procedure from within my
ASP page, the script always waits for the stored proc to complete before
continuing. If I move the code to global.asa so that the "waiting jobs"
table is checked every time a new session is started, I find that every time
a new job is waiting the user has to wait extra long for their first page to
load. (Plus, as much as I'd like to, I have no way to guarantee that there
will be new visitors every five minutes!)

So, since I have no way to interact with Task Scheduler or SQL Server Agent,
can you suggest another way to regularly poll the jobs table and execute
waiting jobs WITHOUT causing a delay for the user? (Something like async
execution of a stored proc from the ASP would be great, but I don't know how
to do that.)

Thanks so much!

Perhaps create a trigger that runs sp_start_job xxx after inserts to the
job table? But that may not be possible; sounds like your ISP has the
system tightened down.

There are lots of posts at
http://www.google.com/[email protected]&rnum=7
but I don't know if any would work for you.

Finally, since you can't put a service or program on the ISP's system I
can only think of one other way. It's a real kludge and I'm almost
embarrassed to mention it (but I've heard that it has been used in some
quarters in desperation):

Set up a separate secure ASP page, call it MYPAGE.ASP, whose whole
purpose is to check for and execute the long-running jobs one at a time.
Set the Session.timeout appropriately for that page and put a META
REFRESH tag on it, e.g., <META HTTP-EQUIV="REFRESH"
CONTENT="5;URL=MYPAGE.ASP;5">
so that, once it returns, it executes again 5 or so seconds later. Set
up a browser whose whole purpose is to keep MYPAGE.ASP in execution.
Effectively MYPAGE.ASP becomes the "Job Scheduler" spoken of above.
Problem is that such a scheduler won't be nearly as reliable as a
Windows program, scheduled task, or asynchronous SP. Losing a network
connection could stop such a scheduler.

Given the constraints, your solution may be the only reasonable one.

Good Luck,
Michael D. Kersey
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top