You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Douglas Theobald <th...@colorado.edu> on 2003/08/10 21:58:58 UTC
mp1 rflush() and buffer size
I have a question concerning the proper behavior of rflush() with mp1. I'm
using Apache/1.3.28 and mod_perl/1.28 on OSX jaguar 10.2.6. Overall mp1
appears to work great. However, the following code does not work as
expected:
use CGI ();
my $r = shift;
my $q = new CGI;
print $q->header('text/html');
print $q->start_html;
print $q->p("Searching...Please wait");
$r->rflush;
# imitate a lengthy operation
for (1..3) {
sleep 1;
}
print $q->p("Done!");
The "Searching...Please wait" text does not display until the sleeps are
done. Adding $|=1; up top does not help. However, this code does work:
use CGI ();
my $r = shift;
my $q = new CGI;
print $q->header('text/html');
print $q->start_html;
for (1..263)
{
print $q->p("Searching...Please wait");
}
$r->rflush;
# imitate a lengthy operation
for (1..3) {
sleep 1;
}
print $q->p("Done!");
It appears that if I print out over 8k, the buffers flush. Less than that,
no flush. Is this proper behavior? And, if so, is there a parameter I can
change somewhere to lower the value or force a flush regardless of what's in
the buffer? I have tried very hard to find documentation or previous
discussion in this group to no avail.
Douglas
Re: mp1 rflush() and buffer size
Posted by Stas Bekman <st...@stason.org>.
Douglas Theobald wrote:
> On 8/10/03 2:46 PM, "Stas Bekman" <st...@stason.org> a écrit :
>
>
>>Douglas Theobald wrote:
>>
>>>The "Searching...Please wait" text does not display until the sleeps are
>>>done. Adding $|=1; up top does not help. However, this code does work:
>>>
>>>use CGI ();
>>>my $r = shift;
>>>my $q = new CGI;
>>>print $q->header('text/html');
>>>print $q->start_html;
>>>for (1..263)
>>>{
>>> print $q->p("Searching...Please wait");
>>>}
>>>$r->rflush;
>>># imitate a lengthy operation
>>>for (1..3) {
>>> sleep 1;
>>>}
>>>print $q->p("Done!");
>>>
>>>It appears that if I print out over 8k, the buffers flush. Less than that,
>>>no flush. Is this proper behavior? And, if so, is there a parameter I can
>>>change somewhere to lower the value or force a flush regardless of what's in
>>>the buffer? I have tried very hard to find documentation or previous
>>>discussion in this group to no avail.
>>
>>Sounds like you have a buffering proxy in front of your mod_perl server. Test
>>it without any front-end proxy, accessing the back-end server directly.
>
>
> Pardon my ignorance, but I know next-to-nothing about proxies (pointers for
> reading up would be welcome). I setup this custom apache server myself on an
> OSX box. OSX ships with perl 5.6, and I wanted a static mod_perl/apache
> build with perl 5.8.0 (actually I wanted mp2 and Apache2, but can't get
> Apache2 to fireup iff it loads mod_perl.so). So, unless there's a front-end
> proxy hidden from me somewhere or configured by default somehow, I don't
> think that's my problem. My httpd.conf has all proxy stuff commented out and
> should by default send "Pragma: no-cache".
I meant if there is something between your mod_perl server and the client,
that could buffer things up, e.g. mod_proxy.
>>If you don't believe that it works, you can run strace on the process, to see
>>it working correctly. You can see an example here:
>>http://perl.apache.org/docs/1.0/guide/debug.html#Detecting_Aborted_Connections
>
>
> Thanks, I ran ktrace on the code above with an additional "print $q->h3("PID
> = $$");" line inserted. Part of it is below. As you thought, it looks like
> its working to me - it wrote out three chunks, the first two being 4098
> bytes.
ah, you should probably add sleep(1) calls between the perl calls so you will
be able to see them between the write calls. Otherwise it's hard to tell
whether it really works or not. Like so:
for (1..3) {
$r->print($_);
$r->rflush;
sleep 1;
}
>BTW, looks like somebody needs to sub an 'eq' for a '==' in the httpd
> code somewhere.
> 13247 httpd GIO fd 2 wrote 73 bytes
> "Argument "en-US" isn't numeric in numeric eq (==) at (eval 124) line
> 40.
> "
I doubt this has to do anything with mod_perl. some locale stuff?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp1 rflush() and buffer size
Posted by Douglas Theobald <th...@colorado.edu>.
On 8/10/03 2:46 PM, "Stas Bekman" <st...@stason.org> a écrit :
> Douglas Theobald wrote:
>> The "Searching...Please wait" text does not display until the sleeps are
>> done. Adding $|=1; up top does not help. However, this code does work:
>>
>> use CGI ();
>> my $r = shift;
>> my $q = new CGI;
>> print $q->header('text/html');
>> print $q->start_html;
>> for (1..263)
>> {
>> print $q->p("Searching...Please wait");
>> }
>> $r->rflush;
>> # imitate a lengthy operation
>> for (1..3) {
>> sleep 1;
>> }
>> print $q->p("Done!");
>>
>> It appears that if I print out over 8k, the buffers flush. Less than that,
>> no flush. Is this proper behavior? And, if so, is there a parameter I can
>> change somewhere to lower the value or force a flush regardless of what's in
>> the buffer? I have tried very hard to find documentation or previous
>> discussion in this group to no avail.
>
> Sounds like you have a buffering proxy in front of your mod_perl server. Test
> it without any front-end proxy, accessing the back-end server directly.
Pardon my ignorance, but I know next-to-nothing about proxies (pointers for
reading up would be welcome). I setup this custom apache server myself on an
OSX box. OSX ships with perl 5.6, and I wanted a static mod_perl/apache
build with perl 5.8.0 (actually I wanted mp2 and Apache2, but can't get
Apache2 to fireup iff it loads mod_perl.so). So, unless there's a front-end
proxy hidden from me somewhere or configured by default somehow, I don't
think that's my problem. My httpd.conf has all proxy stuff commented out and
should by default send "Pragma: no-cache".
> If you don't believe that it works, you can run strace on the process, to see
> it working correctly. You can see an example here:
> http://perl.apache.org/docs/1.0/guide/debug.html#Detecting_Aborted_Connections
Thanks, I ran ktrace on the code above with an additional "print $q->h3("PID
= $$");" line inserted. Part of it is below. As you thought, it looks like
its working to me - it wrote out three chunks, the first two being 4098
bytes. BTW, looks like somebody needs to sub an 'eq' for a '==' in the httpd
code somewhere.
dulcinea/theobal> kdump -f ktrace.out
13247 httpd RET read 377/0x179
13247 httpd CALL sigaction(0x1e,0xbfff8650,0xbfff86c0)
13247 httpd RET sigaction 0
13247 httpd CALL gettimeofday(0xbfff86c0,0)
13247 httpd RET gettimeofday 1060559575/0x3f36dad7
13247 httpd CALL stat(0x662f30,0x6621b0)
13247 httpd NAMI "/usr/local/apache/modperl/rflush.pl"
13247 httpd RET stat 0
13247 httpd CALL sigaction(0xe,0,0xbfffa5c0)
13247 httpd RET sigaction 0
13247 httpd CALL dup2(0xf,0x2)
13247 httpd RET dup2 2
13247 httpd CALL stat(0x45e390,0x2a4a34)
13247 httpd NAMI "/usr/local/apache/modperl/rflush.pl"
13247 httpd RET stat 0
13247 httpd CALL chdir(0xbfff7f50)
13247 httpd NAMI "/usr/local/apache/modperl"
13247 httpd RET chdir 0
13247 httpd CALL issetugid
13247 httpd RET issetugid 1
13247 httpd CALL lstat(0xbfff7a00,0xbfff7940)
13247 httpd NAMI "/usr/share/zoneinfo/GMT"
13247 httpd RET lstat 0
13247 httpd CALL open(0xbfff7a00,0,0x60)
13247 httpd NAMI "/usr/share/zoneinfo/GMT"
13247 httpd RET open 4
13247 httpd CALL fstat(0x4,0xbfff79a0)
13247 httpd RET fstat 0
13247 httpd CALL read(0x4,0xbfff7e10,0x1f08)
13247 httpd GIO fd 4 read 56 bytes
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\^A\0\0\0\0\0\0\0\0\
0\0\0\^A\0\0\0\^D\0\0\0\0\0\0GMT\0\0\0"
13247 httpd RET read 56/0x38
13247 httpd CALL close(0x4)
13247 httpd RET close 0
13247 httpd CALL write(0x2,0x3f0790,0x49)
13247 httpd GIO fd 2 wrote 73 bytes
"Argument "en-US" isn't numeric in numeric eq (==) at (eval 124) line
40.
"
13247 httpd RET write 73/0x49
13247 httpd CALL write(0x3,0x6600a0,0x1002)
13247 httpd GIO fd 3 wrote 4098 bytes
"HTTP/1.1 200 OK\r
Date: Sun, 10 Aug 2003 23:52:55 GMT\r
Server: Apache/1.3.28 (Darwin) mod_perl/1.28\r
Keep-Alive: timeout=15, max=99\r
Connection: Keep-Alive\r
Transfer-Encoding: chunked\r
Content-Type: text/html; charset=ISO-8859-1\r
\r
f14\r
<?xml version="1.1" encoding="iso-8859-1"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1"
"http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en"><head><title>Untitled Document</title>
</head><body><h3>PID = 13247</h3><p>Searching...Please
wait</p><p>Searching...Please wait</p><p>Searching...Please wait</p>
Etc.
Re: mp1 rflush() and buffer size
Posted by Stas Bekman <st...@stason.org>.
Douglas Theobald wrote:
> I have a question concerning the proper behavior of rflush() with mp1. I'm
> using Apache/1.3.28 and mod_perl/1.28 on OSX jaguar 10.2.6. Overall mp1
> appears to work great. However, the following code does not work as
> expected:
>
> use CGI ();
> my $r = shift;
> my $q = new CGI;
> print $q->header('text/html');
> print $q->start_html;
>
> print $q->p("Searching...Please wait");
>
> $r->rflush;
> # imitate a lengthy operation
> for (1..3) {
> sleep 1;
> }
> print $q->p("Done!");
>
> The "Searching...Please wait" text does not display until the sleeps are
> done. Adding $|=1; up top does not help. However, this code does work:
>
> use CGI ();
> my $r = shift;
> my $q = new CGI;
> print $q->header('text/html');
> print $q->start_html;
> for (1..263)
> {
> print $q->p("Searching...Please wait");
> }
> $r->rflush;
> # imitate a lengthy operation
> for (1..3) {
> sleep 1;
> }
> print $q->p("Done!");
>
> It appears that if I print out over 8k, the buffers flush. Less than that,
> no flush. Is this proper behavior? And, if so, is there a parameter I can
> change somewhere to lower the value or force a flush regardless of what's in
> the buffer? I have tried very hard to find documentation or previous
> discussion in this group to no avail.
Sounds like you have a buffering proxy in front of your mod_perl server. Test
it without any front-end proxy, accessing the back-end server directly.
If you don't believe that it works, you can run strace on the process, to see
it working correctly. You can see an example here:
http://perl.apache.org/docs/1.0/guide/debug.html#Detecting_Aborted_Connections
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com