Re: Stop button (was: Re: General Question)
Bill Moseley wrote: > At 02:02 PM 02/26/01 +, Steve Hay wrote: > >I have a script which I wish to run under either mod_perl or CGI which does > >little more than display content and I would like it to stop when the user > >presses Stop, but I can't get it working. > > You need to do different things under mod_perl and mod_cgi. Refer to the > Guide for running under mod_perl -- you probably should check explicitly > for an aborted connection as the guide shows. Oh dear. The program has to run on various different machines around the place, some of which run Apache/mod_perl and some of which run Microsoft IIS/CGI, so I really want one solution which works in both environments if at all possible. > [This is all from my memory, so I hope I have the details correct] > > Under mod_cgi Apache will receive the SIGPIPE when it tries to print to the > socket. Since your CGI script is running as a subprocess (that has been > marked "kill_after_timeout", I believe), apache will first close the pipe > from your CGI program, send it a SIGTERM, wait three seconds, then send a > SIGKILL, and then reap. This all happens in alloc.c, IIRC. > > This is basically the same thing that happens when you have a timeout. > > So, you can catch SIGTERM and then have three seconds to clean up. You > won't see a SIGPIPE unless you try to print in that three second gap. I'm fairly sure the program does print in any given three second gap -- I see the "x"s appearing in my browser window (since output is "unbuffered") at the rate of two or three per second, so I really should get the SIGPIPE. I've also tried adding in a similar handler to try and catch a SIGTERM and exit(), but that doesn't seem to work either. Has anybody else had any luck responding to "Stop" on NT? Cheers, Steve Hay
Re: Stop button (was: Re: General Question)
At 02:02 PM 02/26/01 +, Steve Hay wrote: >I have a script which I wish to run under either mod_perl or CGI which does >little more than display content and I would like it to stop when the user >presses Stop, but I can't get it working. You need to do different things under mod_perl and mod_cgi. Refer to the Guide for running under mod_perl -- you probably should check explicitly for an aborted connection as the guide shows. [This is all from my memory, so I hope I have the details correct] Under mod_cgi Apache will receive the SIGPIPE when it tries to print to the socket. Since your CGI script is running as a subprocess (that has been marked "kill_after_timeout", I believe), apache will first close the pipe from your CGI program, send it a SIGTERM, wait three seconds, then send a SIGKILL, and then reap. This all happens in alloc.c, IIRC. This is basically the same thing that happens when you have a timeout. So, you can catch SIGTERM and then have three seconds to clean up. You won't see a SIGPIPE unless you try to print in that three second gap. Does it do the same thing under NT? Bill Moseley mailto:[EMAIL PROTECTED]
Re: Stop button (was: Re: General Question)
Hi,
Stas Bekman wrote:
> Apache 1.3.6 and up -- STOP pressed:
>
> the code keeps on running until it tries to read from or write to the
> socket. the moment this happens, the script will stop the execution, and
> run cleanup phase.
>
> I think it's the same under mod_perl and mod_cgi. Am I right?
I have a script which I wish to run under either mod_perl or CGI which does
little more than display content and I would like it to stop when the user
presses Stop, but I can't get it working.
I've been trying to figure things out with the following test program:
---
use strict;
use warnings;
$SIG{PIPE} = \&handler;
$| = 1;
print "Content-Type: text/plain\n\n";
for (;;) {
for (1 .. 100) { ; }
print "x\n";
}
sub handler {
# Unreliable signals on NT:-
$SIG{PIPE} = \&handler;
exit;
}
---
(The pointless time-wasting loop just before each print() is so that I can
easily see whether the program actually has exited or not -- I'm running on NT
(groan!) and I can see in my "Task Manager" display that the Apache child
process is flat out 100% CPU while its running.)
I would expect that when the user presses Stop and the script next tries a
print() it'll get a SIGPIPE, call the handler(), and exit().
But it doesn't -- the Apache child process just carries on at 100% CPU.
It makes no difference whether I run it under mod_perl or mod_cgi (except that,
of course, I get a Perl process at 100% CPU instead of the Apache child), and it
also makes no difference if I take out the first "$SIG{PIPE} = \&handler;" line
(and rely on mod_perl to handle the SIGPIPE for me as Stas described above)
and/or put the "PerlFixupHandler Apache::SIG" directive in my httpd.conf.
Can anybody help/explain?
I'm running Apache/1.3.17 and mod_perl/1.25 on Windows NT 4.
Cheers,
Steve Hay
RE: General Question
Hi,
Is this the thing you want?
(otherwise please describe your problem more elaborately.)
print
"Content-Type: text/html\n\n";
print
"html message here";
print "\n";
print
"html message here";
Bye
Muthu
S Ganesh
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Kiran Kumar.MSent: 16 February 2001 13:36To:
modperlSubject: General Question
hi,
I would like to know what
header to print to view this on the browser, if text/html is entered the image
is not displayed and if image/gif is entered the image does not appear ,
thanks in advance
Kiran
ps: if this is not the right place to ask this
question please tell me where i can find help
open(F1,"images.gif")
||errorhandler;
while() {
$imgcont
.=$_;}
close(F1);
print" html message here";
print $imgcont;
print" html message
here";
Re: General Question
Hi there, On Fri, 16 Feb 2001, Kiran Kumar.M wrote: > I would like to know what header to print to view this on the browser Your question is not very clear, are you using mod_perl? If so how is it configured? Have you read .../mod_perl/SUPPORT? Have you seen the Eagle Book? Have you read the Guide? Stas Bekman's mod_perl Guide: http://perl.apache.org/guide/ The Eagle Book: "Writing Apache Modules with Perl and C", ISBN 1-56592-567-X, by Lincoln Stein and Doug MacEachern. It is available from O'Reilley (www.oreilly.com) and of course from Jubilee Office Supplies (www.jubileegroup.co.uk). 73, Ged.
Re: Stop button (was: Re: General Question)
On Sun, 11 Feb 2001, Bill Moseley wrote:
> I don't know why I have to learn this fresh again each time -- it appears
> I'm confusing mod_perl and mod_cgi.
>
> Let's see if I have this right. Under mod_perl and apache >= 1.3.5 if the
> client drops the connection Apache will ignore it (well it might print an
> info message to the log file about "broken pipe"). This means a running
> mod_perl script will continue to run to completion, but the $r->prints go
> nowhere.
>
> The old Apache behavior of killing your running script can be restored
> using Apache::SIG -- which is something you would not want to use if you
> were doing anything besides displaying content, I'd think.
>
> $r->connection->aborted can be used to detect the aborted connection (as
> Stas shows in the Guide). That sounds like a better way to deal with
> broken connections.
>
> Does all that sound right?
Yeah, it's a bit confusing.
Apache 1.3.6 and up -- STOP pressed:
the code keeps on running until it tries to read from or write to the
socket. the moment this happens, the script will stop the execution, and
run cleanup phase.
I think it's the same under mod_perl and mod_cgi. Am I right?
> Are there still issues with doing this?
>
>local $SIG{PIPE} = sub { $aborted++ };
you do this because you want it to be mod_cgi back compatible? If not this
would be better:
END {
$aborted++ if $r->connection->aborted;
}
And if you catch the signal you should do something about it other than
incrementing the count, right? like exit()
> Then mod_cgi I'm still unclear on.
>
> The cgi application does receive the SIGPIPE... well it did 1/2 hour ago
> before I rebooted my machine. Now I can't seem to catch it.
> But, printing again after the SIGPIPE will kill the CGI script.
Well, it doesn't know that it was aborted before you try print something.
I guess the explanation in the guide is not clear enough and should be
revised, especially per Doug's reply... any volunteers?
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: General Question
Yes, I remember Gunther recommending the javascript approach a while back, and I think it is a good solution, but I just can't stand javascript. I always surf with it turned off, because it frequently causes my browser to hang. It's a personal hang-up. I was really interested in just learning how the server handled it, and Stas squared me away. My fear was that it would cause my server to hang, which was my usual experience under Windows NT, but my Linux box just slows to a crawl, and doesn't hang. I can live with that. :) Have a good night! Mike Wojcikiewicz wrote: > > If youre looking for a solution, i suggest putting in a little javascript > on the form.. > > > ... > > > > > as for the other processes, its been my experience that they complete and > die off after apache is done... ie lagging your server to hell.. depends > on your configuration though > > Michael Wojcikiewicz > Web Application Developer > E-Mail: [EMAIL PROTECTED] > ICQ: 944221 > > On Sun, 11 Feb 2001, Buddy Lee Haystack wrote: > > > Situation: > > I press the submit button on a form 55 times in 15 seconds. Each request would >normally return data to the browser within ten seconds due to the time it takes the >database query to execute. > > > > > > Question: > > What happens to the 54 earlier processes, since I submitted the request 55 times? >How do Apache & mod_perl handle the processes to nowhere? > > > > Thanks!
Re: General Question
If youre looking for a solution, i suggest putting in a little javascript on the form.. ... as for the other processes, its been my experience that they complete and die off after apache is done... ie lagging your server to hell.. depends on your configuration though Michael Wojcikiewicz Web Application Developer E-Mail: [EMAIL PROTECTED] ICQ: 944221 On Sun, 11 Feb 2001, Buddy Lee Haystack wrote: > Situation: > I press the submit button on a form 55 times in 15 seconds. Each request would >normally return data to the browser within ten seconds due to the time it takes the >database query to execute. > > > Question: > What happens to the 54 earlier processes, since I submitted the request 55 times? >How do Apache & mod_perl handle the processes to nowhere? > > Thanks! > > > -- > ***NOTE*** > This entire message is confidential, and protected by copyright. If you are not the >intended recipient, you are hereby notified that any review, dissemination or >archiving of this message is strictly prohibited. > ** > > www.RentZone.org >
Re: Stop button (was: Re: General Question)
I don't know why I have to learn this fresh again each time -- it appears
I'm confusing mod_perl and mod_cgi.
Let's see if I have this right. Under mod_perl and apache >= 1.3.5 if the
client drops the connection Apache will ignore it (well it might print an
info message to the log file about "broken pipe"). This means a running
mod_perl script will continue to run to completion, but the $r->prints go
nowhere.
The old Apache behavior of killing your running script can be restored
using Apache::SIG -- which is something you would not want to use if you
were doing anything besides displaying content, I'd think.
$r->connection->aborted can be used to detect the aborted connection (as
Stas shows in the Guide). That sounds like a better way to deal with
broken connections.
Does all that sound right?
Are there still issues with doing this?
local $SIG{PIPE} = sub { $aborted++ };
Then mod_cgi I'm still unclear on.
The cgi application does receive the SIGPIPE... well it did 1/2 hour ago
before I rebooted my machine. Now I can't seem to catch it.
But, printing again after the SIGPIPE will kill the CGI script.
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: General Question
[EMAIL PROTECTED] (Buddy Lee Haystack) wrote: >Situation: >I press the submit button on a form 55 times in 15 seconds. Each >request would normally return data to the browser within ten seconds >due to the time it takes the database query to execute. > > >Question: >What happens to the 54 earlier processes, since I submitted the request 55 >times? How do Apache & mod_perl handle the processes to nowhere? The output of the other processes goes to Belgium. Some of it goes to New Zealand too, but mostly to Belgium. Pretty soon it's going to really start piling up, and someone's going to have to start taking care of it. Volunteer bit shovelers are appreciated. (Sorry, couldn't resist. =) ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Stop button (was: Re: General Question)
At 08:43 AM 02/12/01 +0800, Stas Bekman wrote:
>> What happens to the 54 earlier processes, since I submitted the request
55 times? How do Apache & mod_perl handle the processes to nowhere?
>
>They get aborted the first moment they try to send some output (or read
>input if they didn't finish yet) and after that get aborted as they
>realize that the connection to the socket is dead. See:
>http://perl.apache.org/guide/debug.html#Handling_the_User_pressed_Stop_
I thought one has to explicitly check for the aborted connection in >=
1.3.5 -- like you explain in the section in the Guide following the one you
cited. Isn't $r->print a noop after an aborted connection?
Which gives me a chance to ask an off topic question about this very topic:
As this arrived at in my inbox I was debugging a pair of old CGI scripts.
Both are very similar and use common modules for most everything -- one is
the public script and the other is the admin script for maintenance and
data entry.Both CGI.
Both scripts use a common module for logging and DBM file opening and
closing. Really, the only difference is the form processing for the two
scripts.
The DBM close is in an END block, and the END block also writes a
"Transaction Done" message to STDERR (STDERR is dup'ed to a log file I use
for locking before at the start of every request the DBM files -- very low
traffic script).
Hitting stop on the public script has no effect -- just like I'd expect for
1.3.12 -- it keeps running even when generating a long-ish output.
But hitting stop on the admin script aborts every time. I have $SIG{PIPE}
= sub { print STDERR "$$ caught sigpipe" exit } in the common module and it
prints the error when I hit stop on the admin script.
Nothing is noted in the apache logs about broken pipes.
I'm scratching my head at this point. Any ideas what to look for?
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: General Question
On Sun, 11 Feb 2001, Buddy Lee Haystack wrote: > Situation: > I press the submit button on a form 55 times in 15 seconds. Each request would >normally return data to the browser within ten seconds due to the time it takes the >database query to execute. > > > Question: > What happens to the 54 earlier processes, since I submitted the request 55 times? >How do Apache & mod_perl handle the processes to nowhere? They get aborted the first moment they try to send some output (or read input if they didn't finish yet) and after that get aborted as they realize that the connection to the socket is dead. See: http://perl.apache.org/guide/debug.html#Handling_the_User_pressed_Stop_ _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
