Finish execution of ASP script when client disconnects

Discussion in 'ASP General' started by Boris Nikolaevich, Sep 3, 2003.

  1. 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
     
    Boris Nikolaevich, Sep 3, 2003
    #1
    1. Advertising

  2. Boris Nikolaevich

    aa Guest

    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
    "Boris Nikolaevich" <> wrote in message
    news:#4Kk#...
    > 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
    >
    >
     
    aa, Sep 3, 2003
    #2
    1. Advertising

  3. 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!


    "aa" <> wrote in message
    news:...
    > 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
    > "Boris Nikolaevich" <> wrote in message
    > news:#4Kk#...
    > > 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
    > >
    > >

    >
    >
     
    Boris Nikolaevich, Sep 3, 2003
    #3
  4. Boris Nikolaevich wrote:
    > 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
     
    Michael D. Kersey, Sep 3, 2003
    #4
  5. Boris Nikolaevich wrote:
    >
    > "Michael D. Kersey" <> wrote in message
    > news:...
    > <snip>
    > > 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.

    >
    > 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/groups?q=asyn...$12241$&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
     
    Michael D. Kersey, Sep 4, 2003
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Remon van Vliet

    Java NIO disconnects unnoticed?

    Remon van Vliet, Nov 29, 2005, in forum: Java
    Replies:
    1
    Views:
    696
    Remon van Vliet
    Dec 1, 2005
  2. rajatag

    Sockets - Mass Disconnects

    rajatag, Jan 14, 2006, in forum: Java
    Replies:
    4
    Views:
    305
    rajatag
    Feb 2, 2006
  3. Manjesh Gowda
    Replies:
    2
    Views:
    396
    Howard
    Sep 2, 2004
  4. pcgallagher
    Replies:
    2
    Views:
    2,469
    Mark Space
    Dec 27, 2008
  5. Gary
    Replies:
    0
    Views:
    187
Loading...

Share This Page