cgi timeout ?

[jbv]

Andre,

Thanks for the suggestion.
Actually what I did first is to re-write my cgi script many times
and optimize it so that it never takes more than 2 or 3 seconds.

I will also implement the technique you describe, although
there's a little additional problem : the "result html" as you name
it is actually a pdf file generated on the fly...

Besides, I don't think the core of my problem of "vanishing cgi"
is related to the execution time or any cgi timeout, but rather to
some random bug of Rev cgi... Actually I vaguely remember someone
(Shari ?) on this very list writing about calls to cgi scripts via the
POST command in a client Rev script that randomly didn't go
through... I have the feeling that I'm facing the same problem :
I've built a small Rev client app to test my Rev cgi on the server
before I implement it on the web site, and I'm having this problem
with the Rev client app ONLY, and NEVER when cgi calls are
made from a web form...

JB

> JB,
>
> I don't think that fiddling with the socket timeout interval is a good
> solution, also hooking a HTTP connection like this is not safe, some
> browsers might just choose to give up. I think the most elegant
> solution would be to split your HTML page in two and work like this:
>
> 1) CLIENT: enter web form for the complex task or jump start that slow
> task.
> 2) CGI: send back a HTML with a meta refresh tag of 15 seconds (more
> then enough). This HTML might have a message like: "Wait while we
> process the task...", there in this HTML you hide some param (in a
> hidden form, in the URL or in a cookie) to tag which calculation you're
> doing, you need this for if two users open the page at the same time,
> you'll be able to show the correct result. After 15 secs, browser
> redirects to the result html. Everyone is happy.
>
> You might generate a unique ID on the CGI jumpstart and append that to
> the result CGI link tag that is present on the waiting HTML page, like:
>
> <meta http-equiv="refresh"
> content="15;url=http://www.myserver.com/cgi-bin/result.cgi?
> uid=923756972356">
>
> with this design you save bandwitdh, you make a easy working CGI that
> can couple with many connections without hogging the whole system and
> you comply with http good manners. If you need further assistance with
> this, just ask.
>
> Cheers
> andre
>
> On May 27, 2005, at 2:59 PM, jbv wrote:
>
> > Hi list,
> >
> > Although I make heavy use of Rev cgi on some projects,
> > I'm far from being an expert on cgi / Apache / Linux /
> > server administration...
> >
> > In some situations (mainly development & debugging),
> > Rev cgi is asked to perform quite complex tasks, and
> > sometimes the execution of a script can take up to 8 or
> > 9 or 10 seconds (I know : it's prohibitive, but in the
> > development process you don't always know in advance
> > if your approach will lead to fast execution or not)...
> > And I noticed that when a task (script execution) reaches
> > the 9 to 11 seconds limit, it doesn't return anything, or
> > IOW it seems to just stop & vanish...
> > So I was wondering if there was a timeout of some sort
> > in the Apache / Linux configuration, and what was the
> > best way to deal with it...
> >
> > Thanks,
> > JB
> >
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> --
> Andre Alves Garzia ? 2004 ? BRAZIL
> http://studio.soapdog.org
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution