Just wanted to comment that that idea won't work on uploads (where the delay
is caused by information in the _request_ taking a long time to process
[read send]).  But I seem to remember hearing someone who was making a patch
to add an upload hook for apache - do I remember correctly?

  Issac

----- Original Message -----
From: "John Hurst" <[EMAIL PROTECTED]>
To: "Matthew Darwin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, May 26, 2001 12:00 AM
Subject: Re: Handling the 'User pressed Stop button' case - not working


> Matthew Darwin wrote:
>
> > On Sat, 26 May 2001, Stas Bekman wrote:
> >
> >
> >> You right. It seems that mod_proxy won't abort on SIGPIPE.
> >
> >
> > So how can I get it to without breaking everything else?  Any ideas?
> >
> > I have a process that takes 2-3 minutes to run before the user gets any
> > any output.  I tell them to wait, but they get impatient.  If they hit
> > STOP I really want to know about it so I can free up CPU resources for
> > when they hit RELOAD to try agin.
> >
> > Any helpful hints would be most appreciated.
>
>
> Run the process in the background. Have the browser loop on a reporting
> URL w/request ID. That will allow you to show progress:
>
>   * The initial request generates a processing job. Please see previous
> threads regarding the wisdom of forking mod_perl processes. You may want
> to consider writing a lightweight daemon to take processing requests
> from mod_perl via a unix domain socket.
>
>   * Return a "starting" page to the client which will refresh to a
> progress reporting URL, which may be the same URL as the original
> request (be sure to include a UUID or some other identifier for the job).
>
>   * Each time the progress URL is called, check on the status of the
> processing job. Return the data if available, or return another refresh.
>
> Also:
>
>   * The progress URL can use the UUID to generate updated status info.
> If you are clever, you can even offer a status bar.
>
>   * If you keep the results of your processing jobs indexed by, say, the
> MD5 of the request parameters that created them, you can skip redundant
> processing runs.
>
>
> -jh
>

Reply via email to