Re: OT: forking so apache won't wait
On Thu, Sep 27, 2001 at 12:44:35AM -0500, will trillich wrote:
>
> debianistas tend to know where to look, so i'm hoping someone
> will point the way--
sure :)
> i know i've run across it before but when i WANT to stub my toe
> on it, it's nowhere to be found: HOW can i have apache/web page
> initiate a process and return quickly to generate a 'processing,
> hold on' page while the process does its processing?
>
> <snip>
>
> pointers? flames? any gdM you think i should RTF out of?
Hi Will,
...as I've seen you being active on the mod_perl list, I would've
assumed that you've already heard of "The Guide" ;)
Basically, there's nothing wrong with your concept of forking off the
long-running process, and as a normal CGI program it would probably
work fine. The few remaining flaws in it (specific to the mod_perl
environment) are all detailed in the mentioned docs.
So, just in case you'd like to pursue your original idea (instead of
using the multipart/x-mixed-replace MIME-type method), you probably
want to start reading here:
http://perl.apache.org/guide/performance.html#Forking_and_Executing_Subprocess
Also, if you haven't already thought of this, you might consider
sending back a 'waiting'-document that automatically keeps pulling the
server in certain intervals. Just include the following in the HEAD
section of that html page
<HTML>
<HEAD>
<META HTTP-EQUIV="refresh" content="5; URL=...(your URI here)">
</HEAD>
...
to have it check back/reload after 5 secs. In the most simple case, the
remote process you call via this URI would check whether there exists
some result file (indicating that the long running process has
completed), and, if so, send back the final result page, if not, resend
the wait page.
What also often comes in handy is the not so well known HTTP return
code "Status: 204 No Content", which causes the browser to *not*
update/delete its currently displayed page -- it's a kinda 'do nothing'
instruction. For example, returning this 204 while the process is still
running, avoids having to resend/redraw the wait-page, and the
associated flickering...
The above refresh technique does, however, not work in combination with
the 204 trick. It would reload exactly once, as the "no content"-page
cannot resend the same html code snippet, of course (and sending a real
HTTP "Refresh: ..." header after the the "Status: 204" does not seem to
work -- at least not with Netscape. So, for this to work, you would
need a bit of javascript, something like:
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
function check_done() {
this.location.replace("http://your.server/path/check-done.url";);
}
</SCRIPT>
</HEAD>
<BODY onLoad="setInterval('check_done()', 5000)">
Processing... Please wait...
</BODY>
</HTML>
(the setInterval() period is in msecs)
Cheers
--
Erdmut Pfeifer
science+computing ag
www.science-computing.de
-- Bugs come in through open windows. Keep Windows shut! --
Reply to: