RE: Updating $r->connection->aborted before $r->print() ?

2001-09-14 Thread Geoffrey Young



> -Original Message-
> From: Joshua Chamas [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 14, 2001 3:21 PM
> To: Mod Perl
> Subject: Updating $r->connection->aborted before $r->print() ?
> 
> 
> Hey,
> 
> In my own experience it seems that I can only get
> $r->connection->aborted updated if I first do a $r->print().
> Is there any way to get aborted to update without 
> $r->print?

my $fileno = $r->connection->fileno;

$s = IO::Select->new($fileno);

die "aborted" if grep { m/$fileno/ } $s->can_read(1);

HTH

--Geoff 



Re: Updating $r->connection->aborted before $r->print() ?

2001-09-15 Thread Stas

Geoffrey Young wrote:
> 
>>-Original Message-
>>From: Joshua Chamas [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, September 14, 2001 3:21 PM
>>To: Mod Perl
>>Subject: Updating $r->connection->aborted before $r->print() ?
>>
>>
>>Hey,
>>
>>In my own experience it seems that I can only get
>>$r->connection->aborted updated if I first do a $r->print().
>>Is there any way to get aborted to update without 
>>$r->print?
>>
> 
> my $fileno = $r->connection->fileno;
> 
> $s = IO::Select->new($fileno);
> 
> die "aborted" if grep { m/$fileno/ } $s->can_read(1);


Hmm, does this actually work Geoff? What happens if mod_perl is running 
as a back-end? In this case $r->connection->aborted doesn't work even if 
you print.

Joshua, what about print "\0", I'm not sure whether this messes up the 
headers. given that you end these tests with a new line.

_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/





RE: Updating $r->connection->aborted before $r->print() ?

2001-09-15 Thread Geoffrey Young

 



>> my $fileno = $r->connection->fileno;



>> 



>> $s = IO::Select->new($fileno);



>> 



>> die "aborted" if grep { m/$fileno/ } $s->can_read(1);



>



>



>Hmm, does this actually work Geoff? What happens if mod_perl is running 



>as a back-end? In this case $r->connection->aborted doesn't work even if






>you print.





yes, it worked for me.  actually, I guess I should have been clearer - this
has nothing to do with $c->aborted or $r->print (well, on the outside
anyway).  for $c->aborted you have to wait for Apache to flush the print
buffers.  actually, in my tests $r->rflush didn't help things behave - only
$|=1 did.  

$s->can_read should always work because Apache marks the client output file
descriptor with a zero-length packet for reading when the client dies.  so,
when you can read from where you ought to be writing, you can assume a
broken connection.

at least this is my understanding. wish I could take credit, though - Eric
discovered/documented this one a while ago:)

at any rate, this worked for me just fine in some tests, but I never tested
it against a front-end/back-end setup.  seems like you would never be able
to detect a broken client connection from in a proxy setup anyway, but
that's not my area to comment on...

--Geoff



RE: Updating $r->connection->aborted before $r->print() ?

2001-09-17 Thread Stas Bekman

On Sat, 15 Sep 2001, Geoffrey Young wrote:

> >> my $fileno = $r->connection->fileno;
> >> $s = IO::Select->new($fileno);
> >>
> >> die "aborted" if grep { m/$fileno/ } $s->can_read(1);
>
> >Hmm, does this actually work Geoff? What happens if mod_perl is running
> >as a back-end? In this case $r->connection->aborted doesn't work even if
> >you print.
>
> yes, it worked for me.  actually, I guess I should have been clearer - this
> has nothing to do with $c->aborted or $r->print (well, on the outside
> anyway).  for $c->aborted you have to wait for Apache to flush the print
> buffers.  actually, in my tests $r->rflush didn't help things behave - only
> $|=1 did.
>
> $s->can_read should always work because Apache marks the client output file
> descriptor with a zero-length packet for reading when the client dies.  so,
> when you can read from where you ought to be writing, you can assume a
> broken connection.
>
> at least this is my understanding. wish I could take credit, though - Eric
> discovered/documented this one a while ago:)

cool! Somehow I've missed this patch.

> at any rate, this worked for me just fine in some tests, but I never tested
> it against a front-end/back-end setup.  seems like you would never be able
> to detect a broken client connection from in a proxy setup anyway, but
> that's not my area to comment on...

I'll give it a run when I get some time to play with it and update the
guide appropriately.

Thanks Geoff!

_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/





Re: Updating $r->connection->aborted before $r->print() ?

2001-09-17 Thread Joshua Chamas

Geoffrey Young wrote:
> 
> my $fileno = $r->connection->fileno;
> 
> $s = IO::Select->new($fileno);
> 
> die "aborted" if grep { m/$fileno/ } $s->can_read(1);
> 
> HTH
> 

Thanks for this.  The code that I ended up using for Apache::ASP was:

# IsClientConnected ?  Might already be disconnected for busy site, if
# a user hits stop/reload
my $is_connected = 1;
my $fileno = $r->connection->fileno;
if(defined $fileno) {
my $s = IO::Select->new($fileno);
if($s->can_read(0)) {
$is_connected = 0;
}
}

The difference being the can_read(0) from can_read(1).
The 1 would create an unnecessary wait of 1 second I found,
whereas 0 does not, yet reports the aborted condition
accurately.

Thanks again!

-- Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: Updating $r->connection->aborted before $r->print() ?

2001-09-20 Thread Joshua Chamas

Geoffrey Young wrote:
>
> yes, it worked for me.  actually, I guess I should have been clearer - this
> has nothing to do with $c->aborted or $r->print (well, on the outside
> anyway).  for $c->aborted you have to wait for Apache to flush the print
> buffers.  actually, in my tests $r->rflush didn't help things behave - only
> $|=1 did.
> 

Hey Geoff, for efficiency, my final code for detecting a client abort is:

sub Apache::ASP::Response::IsClientConnected {
...
# IsClientConnected ?  Might already be disconnected for busy site, if
# a user hits stop/reload
my $conn = $self->{r}->connection;
my $is_connected = $conn->aborted ? 0 : 1;
if($is_connected) {
my $fileno = $conn->fileno;
if(defined $fileno) {
my $s = IO::Select->new($fileno);
$is_connected = $s->can_read(0) ? 0 : 1;
}
}

where $self is the ASP object ... I looked at the IO::Select->new()
and it looked pretty hairy, so I checked connection->aborted
status first in case it was already set.

-- Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



RE: Updating $r->connection->aborted before $r->print() ?

2001-09-20 Thread Geoffrey Young


>Hey Geoff, for efficiency, my final code for detecting a client abort
>is:

[snip]

>where $self is the ASP object ... I looked at the IO::Select->new()
>and it looked pretty hairy, so I checked connection->aborted
>status first in case it was already set.

good idea.  thanks for following up...

--Geoff