Let me rephrase what I did to solve this problem. I wrote a web stats package that consisted of a sequence of perl programs that analyzed web log files on a user-demand basis. Depending on the size of the Apache log file, these sequence of programs could and did time out when run as part of a CGI script with a client waiting on its output. So here is what I did:

1. User specifies statistics that she wants in an HTML form, presses Submit button.

2. Submit goes to a self-refreshing CGI script that kicks off the sequence of perl programs as an asynchronous subprocess (I think I simply used system("stats.pl parms &");)
(stats.pl then executes the sequence of perl programs that actually does the statistical analysis of the log file)


3. The sequence of perl programs creates a temporary status/lock file with a name that identifies this stats run uniquely (user id . process id . epoch or something like that)

4. The sequence of perl programs writes status/completion information to a file.

5. The self-refreshing CGI script, meanwhile, reads status information from the same file, formats it, and displays output to the user.
(Output refreshes every 5 seconds or so.)


6. The sequence of perl programs creates the statistics HTML pages, and then, the last thing it does is delete the status file.

7. When the self-refreshing CGI script detects that the status file has been deleted, it knows that the sequence of perl programs is done, and redirects to the HTML page(s) showing the web statistics.

A bit involved but it turned out to be pretty robust. The problem of kill -9'ing subprocesses if the user requests a job abort is left as an exercise for the reader (because I forget how I did it.) ;-)

Tony

T. William Schmidt wrote:

All of this is very problematic to achieve robustness given the nature of browsers and the http protocol. Can you redesign the programs so that once one is launched it does not depend on a continuous browser connection? Make the database programs asynchronous. If the user who requested the transaction must be notified of the program's completion status, send the confirmation by email.

Will

At 05:38 PM 6/20/2004 -0700, Anthony Nemmer wrote:

[EMAIL PROTECTED] wrote:


In a message dated 20/06/2004 17:48:21 GMT Daylight Time, [EMAIL PROTECTED] writes:

I maintain an administration site that allows users to execute perl
programs using their web browser. I've run into a couple programs that
do not complete execution prior to the browser timing out. When the
browser quits, the perl program quits before it's done. I end up with a
mess because these perl programs are manipulating our database.


Question?  How can I force the browser connection to stay active  until
after a perl program finishes execution?

The only work around I've found is to run from the command line. This
connection never quits before it's time.


I appreciate any  advice on this.



Not really been able to find a way around this, but I did have a similar problem. One solution is to keep writing something to the browser (eg, a series of dots to show progress), this tends to keep it active, but may not be practical.
The best solution is to implement a lock-out whilst the perl program is
running, so that it cannot be run more than once at a time. Simple to do - just set a value in an external file.
This can also be used to allow you to interrogate what the perl program is
currently doing.

Better than that, write status information to the file and metarefresh the browser with a cgi script that reads from the status file and displays how far the perl program has gotten or what it is doing. You kill a couple of birds with one file this way.


Tony

--
Rich  Mellor RWAP Services
35 Chantry Croft, Kinsley, Pontefract, West  Yorkshire, WF9 5JH
TEL: 01977 610509
Visit our website at  URL:http://www.rwapsoftware.co.uk

Stuck with ordinary dial up internet connection ?? Read our review of internet accelerators and broadband at:
URL: http://www.rwapadventures.com/Services/reviews.html





------------------------------------------------------------------------

_______________________________________________
ActivePerl mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs



--

SKYKING, SKYKING, DO NOT ANSWER.


_______________________________________________ ActivePerl mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs


Regards,
Will Schmidt

WilliamSchmidt.com, LLC
11201 NW 77th Street
Terrebonne, OR  97760
541 504-0290
[EMAIL PROTECTED]
http://www.williamschmidt.com/





--

SKYKING, SKYKING, DO NOT ANSWER.


_______________________________________________ ActivePerl mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to