You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "David D. Kilzer" <da...@e-markets.com> on 2000/07/22 02:18:17 UTC
Re: Apache & Browser
NOTE: This thread should really move to the mod_perl mailing list.
Subscription info is here: http://perl.apache.org/#maillists
Actually, using the Apache::SIG module will do what you want.
http://search.cpan.org/doc/DOUGM/mod_perl-1.24/lib/Apache/SIG.pm
There are some caveats. I don't remember if all of these are required
to make it work (some experimentation is necessary):
o The behavior is broken among certain versions of Apache 1.3.x,
mod_perl 1.x and/or Perl 5.00x. (I know the behavior is broken in
some cases, but I don't remember which ones. I think it was a bug
in early versions of Apache 1.3.x, where "early" is approximately
less than 1.3.6.)
o The CGI script must be actively printing output to the client during
the loop where you want to catch the 'Stop' action. THIS IS THE
MOST IMPORTANT CAVEAT! Note that you print 'null' characters (or
perhaps spaces) instead of actual content, but it would be best to
print content if possible.
o You must install a new handler for SIGPIPE (using Apache::SIG) to
handle the finish() and the disconnect(). This is more of a
required step than a caveat, though.
The mod_perl mailing list is archived on geocrawler.com (among other
places). Search for 'SIGPIPE' on the list for more details.
http://www.geocrawler.com/lists/3/Web/182/0/
http://www.geocrawler.com/search/?config=182&words=SIGPIPE
Also, Oracle generally doesn't take that long to store data unles you're
talking about multi-megabytes, in which case I'd wonder why a web
interface was being used to do that. This is usually an indication that
something else may be wrong (as others have pointed out) with the SQL,
Oracle, the table definitions or other usually trivial things. You may
wish to capture the exact SQL being used to submit to Oracle and
rerunning it through sqlplus, or try running the same code with the same
data in stand-alone mode (outside the web server).
Dave
Steve Sapovits <Sa...@globalsportsinc.com> wrote:
>John is right ... I goofed. It's not until send
>that you see this. Should have realized this. Maybe
>I should actually read the docs I send next time. 8-)
>
>Sorry for the false hope.
>
>The only solution I can see for something that pends
>like db access is to have another thread somehow check
>the connection. But since even that would involve trying
>to send something I'd say you're probably screwed. It's
>not like you can send a pretend response or anything.
>
>How about making those queries faster?
>
>----
>Steve Sapovits
>Global Sports Interactive
>Work Email: sapovitss@globalsports.com
>Home Email: steves@delanet.com
>Work Phone: 610-491-7087
>Cell: 610-574-7706
>Pager: 877-239-4003
>
>> -----Original Message-----
>> From: John Peacock [SMTP:JPeacock@UnivPress.com]
>> Sent: Friday, July 21, 2000 10:57 AM
>> To: Steve Sapovits
>> Cc: St�phane De raco; dbi-users@isc.org
>> Subject: Re: Apache & Browser
>>
>>
>> To quote http://www.mmedia.is/apache/perl/guide/obvious.html:
>>
>> It's important to notice that when the user hits the browser's STOP
>> button, the mod_perl script is blissfully unaware until it tries to send
>> some data to the browser. At that point, Apache realizes that the
>> browser is gone, and all the good cleanup stuff happens.
>>
>> That follows my definition of asynchronous; the server process gets a
>> $SIG{PIPE} but only when some process tries to use the pipe. The perl
>> CGI does not get the signal until it tries to print something to the
>> pipe, some minutes/hours/days later.
>>
>> If you write your CGI app to use server push and run the query in
>> another process, then you might be able to deal with it in a more
>> immediate method. However, I think that at least with Oracle, the perl
>> code itself is waiting for the Oracle client libraries to return from
>> the query. I think only using something like sqlplus can you
>> interactively break a query; I suspect there is no way to do it in perl
>> short of kill the process itself.
>>
>> John Peacock
>>
>> > Steve Sapovits wrote:
>> >
>> > It's a connectionless protocol, but the browser
>> > maintains a connection to the server while waiting
>> > for CGI output. Otherwise the server won't know
>> > where to send the response. That's how the server
>> > knows immediately ... as I remembered when getting
>> > my refresher course after searching. 8-)
>> >
>> > ----
>> > Steve Sapovits
>> > Global Sports Interactive
>> > Work Email: sapovitss@globalsports.com
>> > Home Email: steves@delanet.com
>> > Work Phone: 610-491-7087
>> > Cell: 610-574-7706
>> > Pager: 877-239-4003
>> >
>> > -----Original Message-----
>> > From: John Peacock [SMTP:JPeacock@UnivPress.com]
>> > Sent: Friday, July 21, 2000 10:43 AM
>> > To: Steve Sapovits
>> > Cc: St�phane De raco; dbi-users@isc.org
>> > Subject: Re: Apache & Browser
>> >
>> > Yes, the server knows, but only when it goes to send the
>> > response. This
>> > is too late to do what the user originally asked to do, i.e.
>> > cancel the
>> > query. The nature of web transactions is that it is
>> > asynchronous; the
>> > client can break off a session at any time and the server will
>> > not know
>> > immediately, if at all.
>> >
>> > John Peacock
>> >
>> > Steve Sapovits wrote:
>> > >
>> > > Actually, if you look at server logs, the server does know
>> > > at some point -- I think when it goes to send the response.
>> > > You get those 'broken pipe' or 'connection reset by peer'
>> > > messages. I just don't know if there's a way for a CGI to
>> > > know. I'm checking some docs ...
>> > >
>> > > ----
>> > > Steve Sapovits
>> > > Global Sports Interactive
>> > > Work Email: sapovitss@globalsports.com
>> > > Home Email: steves@delanet.com
>> > > Work Phone: 610-491-7087
>> > > Cell: 610-574-7706
>> > > Pager: 877-239-4003
>> > >
>> > > > -----Original Message-----
>> > > > From: John Peacock [SMTP:JPeacock@UnivPress.com]
>> > > > Sent: Friday, July 21, 2000 10:05 AM
>> > > > To: St�phane Deraco
>> > > > Cc: dbi-users@isc.org
>> > > > Subject: Re: Apache & Browser
>> > > >
>> > > >
>> > > > No; this violates the basic nature of HTTP, which is a
>> > stateless client-
>> > > > server system. Once the client has asked the server to
>> > perform some
>> > > > long running process, the server will not communicate with
>> > the client
>> > > > until it has completed the task (and not even necessarily
>> > then). The
>> > > > client (browser) can hit stop, go to another web page, etc.
>> > and it has
>> > > > absolutely no effect on the server, which has no idea that
>> > the client
>> > > > has moved on.
>> > > >
>> > > > Sorry,
>> > > >
>> > > > John Peacock
>> > > >
>> > > > "St�phane Deraco" wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > Can anyone tell me if Apache can execute some Perl script
>> > when a user
>> > > > click on
>> > > > > the 'Stop', 'Back', or 'Close' button while a long SQL
>> > query is being
>> > > > executed.
>> > > > > I'd like to launch a script that will do $sql->finish and
>> > > > $dbd->disconnect.
>> > > > >
>> > > > > Here's my problem : I have a form that collect some
>> > information, and
>> > > > send them
>> > > > > to another script. This script should execute the SQL, and
>> > then, print
>> > > > > results. When I click submit for small SQL queries,
>> > everything's OK. But
>> > > > when
>> > > > > ir's a long query, the browser doesn't display the header
>> > of the second
>> > > > > script, even after one night...
>> > > > > I already use eval{} blocks and I disconnect if something's
>> > wrong, but
>> > > > Oracle
>> > > > > is still doing 'something' : Oracle.exe uses 99% of the
>> > CPU...
>> > > > >
>> > > > > Oracle Server NT 8.1.6
>> > > > > Oracle Client Linux 8.1.6
>> > > > > Apache 1.3.9
>> > > > > Apache::DBI 0.87
>> > > > > mod_perl 1.21
>> > > > > DBD Oracle 1.03
>> > > > > DBI 1.13
>> > > > > Red Hat Linux 6.0
>> > > > >
>> > > > > Thanks in advance
>> > > > >
>> > > > > Steph
>>
>