How to prevent a web client from timing out

[Alexis Iglauer]

It takes a non-technical girlfriend to solve this :)  I simply write
something to the webpage every 60 secs or so (either   or number of
iterations or whatever).  Works like a charm, too.

I might still create a calculation server though, although that will have to
wait until I have more time on my hands again.

Thanks for all the help
aei

"Jeff Bauer" <jbauer at rubic.com> wrote in message
news:393C1660.6A22F08D at rubic.com...
> Alexis Iglauer wrote:
> > The job is different every time, so a cron solution
> > wouldn't work.  The problem is that when the client
> > times out the server kills the python process doing
> > the number crunching
>
> I didn't suggest cron.  (Someone else may have.)
>
> You can basically have a separate process already
> running, waiting for a number-crunching request.
> It is independent of the client, so if the client
> times out, nothing happens to the long-running
> process.
>
> Assume the long-running process (LRP) is threaded,
> and it can report back the status of the operation
> when your client requests it.
>
> Scenario:
>
> 1. Client (cgi script) submits a number-crunching
> request to LRP.
>
> 2. LRP responds back to client, "I'm working
> on it.  Press HERE to check on status."
>
> 3. User presses HERE button and another cgi script
> calls the LRP, which replies, "Gimme a minute,
> will ya?  Jeez."
>
> 4. User presses HERE button again.  Cgi script
> calls the LRP which has now finished the calculation.
> It responds, "The answer is 42."
>
> > So how do I stop apache from killing the process?
>
> Because Apache didn't launch the process, Apache
> won't kill the process.  You do the LRP independent
> of Apache.
>
> > How well does xmlrpc work in the real world?
>
> I don't know about the "real" world, but I've
> created an artificial world where it works pretty
> well.
>
> But for the technique described above, you don't
> *have* to use xmlrpc. Any similar technique (e.g.
> DOPY, Fnorb, ILU) should also prove satisfactory.
>
> Jeff Bauer
> Rubicon Research
>