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@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@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution