Re: Re: Connection: Keep-Alive and Perl

Seems like this would be good for people skipping quickly through many dynamic pages, but I wonder at what user volume or click speed would you start to feel it.

To me this is interesting also in that I have been plagued with a browser closing before a long log file was displayed as running output of a C++ process in unix. Thought I had tried keep-alive correctly (as an header in the html page..) and the only answer I could find would be to use a meta refresh which would reload the page periodically.

So what I have is a perl program called as cgi, which does a lot of processing and calls various C/C++ programs, while it and those process write a detailed log file, and simultaneously the cgi program writes a much more terse description of what is going on to the user's browser. The terseness of the cgi output would cause a browser timeout, and the user would think the C process died and try to launch it again from cgi. (Ouch.)

This causes problems of course, what if it takes longer to load the page than the meta refresh period? (disappears while you are trying to read it, is what happens).

I wonder if writing a Content-Length header with a huge number would keep the browser open indefinitely (i.e. the browser logo would keep spinning forever)?

[dws]

I have been plagued with a browser closing before a long log file was displayed as running output of a C++ process in unix.

Keeping a browser open indefinitely is a trick that you'll need to get your web server to go along with. Web servers have differing strategies for how they handle what they believe to be "runaway" CGIs.

One scheme you might try is to fork a separate process that uses HTTP::Daemon to set up a mini web server, then send back a redirect to the browser to point it to the new process. merlyn described this technique in a recent article (which isn't yet on-line, but the listing is here). This bypasses any of the web servers "runaway" detection. From the HTTP::Daemon process, you can dribble out output to your heart's content.

Oh. You said C++. Never mind.

[shotgunefx]

Keep-Alive in my understanding is really for keeping the server listening to the connection for a time after the initial transaction (So it doesn't have to spawn a new server for the next connection. Say if it's downloading a bunch of images from a web page.)

For keeping the browser around a long time I find that you have to keep talking to it. I have a database converter for a client that can take upwards of 30 minutes to run. What I do to keep the connection alive is by disabling buffering and before the long process I output a message like

"Processing please wait...
(This will take approximently 30 minutes. Go get a cup of coffee.)

Then as I process the data, I print a "." or something after every couple of hundred records (like sftp) so they know it is still going (and hopefully they don't get impatient and hit refresh as the process is HUGE and I don't want to start another one for no reason.)

There is probably a lot of ways to accomplish this. If you are forking I would do something similar and have the parent use sleep to time the printing. Keep in mind this solution is a bad idea if you expect a lot of people to be using these programs as your tying up a lot of resources. For my problem it's fine as only one person runs said program once a day.

-Lee

"To be civilized is to deny one's nature."

[mattr]

Thank you dfs and shotgunefx, two great ideas.

The big problem was browser timeout, which had not solved itself by just printing dots. I do dots a lot, maybe spaces that don't display would be good. For some reason I remember thinking the browser was timing out even with the dots being printed, but obviously the process must have just taken too long.

I had looked at IO::Tee (output to multiple handles) but I guess the answer is really just a fork as shotgunefx suggested. The Perl program directs the spidering and indexing of many websites into separate databases, so I would fork a child for each site, then have the child return a success code on finishing its work. I suppose this would even run more quickly with many children in parallel but I think I'll keep it serial for now to keep the log file readable.

Thanks. I guess I was a little *too* lazy a perl programmer.

[mattr]

Thank you both dws and shotgunefx, I posted a longer reply but it didn't get into the system apparently.

I seem to remember trying periods and the browser timing out anyway, but it was probably just too much time between periods.

This was for a perl program called by cgi which directs the spidering of a number of sites and indexing of them. I had looked at IO::Tee, but since I only want the browser to display a very short summary with the log file containing more detail, in the end a fork and spaces being printed by the parent seems best. I supposed I could run a number of children in parallel but when I've done this in the past I got two activity logs interleaved in one file, so I'll keep it serial for now.

I guess I was *too* lazy a perl coder. :)

[traveler]

I wonder if writing a Content-Length header with a huge number would keep the browser open indefinitely (i.e. the browser logo would keep spinning forever)?

Wouldn't that be the same as not specifying a Content-Length?