Are you meaning somethink like this
http://web.practisoft.cz/notimeout.cgi
Petr Vileta, Czech republic
> 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
And yes, step #5 was a thumb sucker... not only did it display how far
along the stats job had progressed, it also displayed a blue completion
bar! =)
Tony
T. William Schmidt wrote:
Tony,
I will concede you wrote an imaginative program but questioner said
when his programs were interrupted by t
Yes, all my program was doing was generating web statistics html pages
from the raw Apache log files, so no critical database updates were
being performed. In fact, if the stats job was aborted by the user, I
believe that I deleted any stats html pages that HAD been generated,
along with kill
Tony,
I will concede you wrote an imaginative program but questioner said when
his programs were interrupted by timeout, it corrupted his database. Even
if he implemented your solution, he should still take steps to protect the
integrity of his database from unexpected disconnection of any type
Come to think of it, I think the (empty) status file may be created at
an earlier time, before the self-refreshing CGI script or the sequence
of perl programs both get kicked off. The name of the file is then
passed to the CGI script and thence to the sequence of perl programs so
that all know
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
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 t
I generally think that in this case you should consider going asynchronous,
by using something like message queuing - the basic structure as follows :
- User hits page with web browser, identifies self
- Simple little script adds job to queue, returns thank you message to user
- Background process
