You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Martin Wickman <ma...@wickman.com> on 2003/07/31 22:17:06 UTC
Filter brigades with rflush() not working?
Hello
According to [1], $r->rflush() should create a new brigade with
data. It does not. It seems the docs and/or my understanding of this
is in error (probably the latter...).
This is with:
Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
And I am using the streaming filter api.
[1] http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers
Long version below:
-------------------
I have tried to make my outputfilter clever enough so it can handle
being called several times, with tags potentially split between
several brigades.
Now I would like to test this somehow (ie, force mod_perl to call my
filter several times). I tried using $r->rflush(), but cannot get it
to work as I and the docs would expect.
I tried creating a ResponseHandler which explicitly breaks some silly
html data into brigades:
sub handler {
my $r = shift;
$r->content_type('text/html');
$r->log_error ("Cutting");
$r->print ("<html><head> title </head>"); $r->rflush();
$r->print ("<bo"); $r->rflush();
$r->print ("dy> body "); $r->rflush();
$r->print ("</html>");
$r->log_error ("Cutting: end");
return Apache::OK;
}
And then a simple 'DebugFilter' output filter which just prints each chunk:
sub handler : FilterRequestHandler {
my $f = shift;
$f->r->log_error ("DebugFilter called");
$f->print ("DebugFilter called\n");
while ($f->read(my $buffer, 1024)) {
$f->print("CHUNK:$buffer:CHUNK\n");
}
return Apache::OK;
}
And httpd.conf
<Location /test/>
PerlResponseHandler MyApache::Cutter
PerlOutputFilterHandler MyApache::DebugFilter
</Location>
When I run this, I see that DebugFilter gets called 4 times (3
rflush's + 1 eos or something). But the strange thing is that only the
_last_ call contains data. That data is _everything_ nicely
concatenated and not splitted as I would guess.
Here is actual output:
$ wget --quiet -O - http://localhost/test/
DebugFilter called
DebugFilter called
DebugFilter called
DebugFilter called
CHUNK:<html><head> title </head><body> body </html>:CHUNK
And the error_log:
[Thu Jul 31 21:52:42 2003] [error] Cutting: start
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] Cutting: end
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
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
mp1 rflush() and buffer size
Posted by Douglas Theobald <th...@colorado.edu>.
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: rflush() not working as documented?
Posted by Stas Bekman <st...@stason.org>.
Martin Wickman wrote:
> I tried the latest CVS (modperl-2.0_20030810101543) and my code now
> works as expected, ie rflush() splits correctly into brigades. The
> t/api/rflush.t works as well btw.
>
> Excellent!
>
>
>>Is it any different from your code?
>
>
> Your test-code is essentially the same as my code. I guess my modperl
> version had a broken rflush() implementation.
Excellent. Thanks Martin!
__________________________________________________________________
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: rflush() not working as documented?
Posted by Martin Wickman <ma...@wickman.com>.
On Thu, Aug 07, 2003 at 04:46:51PM -0700, Stas Bekman wrote:
>
> Please try the latest mp2 cvs, I've added a new test t/api/rflush.t,
> it tests rflush explicitly (even though it's already used for
> exactly this purpose in several other tests).
[...]
> does it work for you?
I tried the latest CVS (modperl-2.0_20030810101543) and my code now
works as expected, ie rflush() splits correctly into brigades. The
t/api/rflush.t works as well btw.
Excellent!
> Is it any different from your code?
Your test-code is essentially the same as my code. I guess my modperl
version had a broken rflush() implementation.
/Thank you!
Re: rflush() not working as documented?
Posted by Stas Bekman <st...@stason.org>.
Martin Wickman wrote:
Please try the latest mp2 cvs, I've added a new test t/api/rflush.t, it tests
rflush explicitly (even though it's already used for exactly this purpose in
several other tests).
It does exactly what your code does:
sub response {
my $r = shift;
# just to make sure that print() won't flush, or we would get the
# count wrong
local $| = 0;
$r->content_type('text/plain');
$r->print("<foo");
$r->rflush; # this sends the data in the buffer + flush bucket
$r->print("bar>");
$r->rflush; # this sends the data in the buffer + flush bucket
$r->print("<who");
$r->rflush; # this sends the data in the buffer + flush bucket
$r->print("ah>");
Apache::OK;
}
Then an output filter that brakets the data:
sub braket {
my $filter = shift;
my $data = '';
while ($filter->read(my $buffer, 1024)) {
$data .= $buffer;
}
$filter->print("[$data]") if $data;
return Apache::OK;
}
the response body is: [<foo][bar>][<who][ah>]
does it work for you? Is it any different from your code?
__________________________________________________________________
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: rflush() not working as documented?
Posted by Martin Wickman <ma...@wickman.com>.
On Wed, Aug 06, 2003 at 07:33:49AM -0700, Stas Bekman wrote:
> Martin Wickman wrote:
[...]
> oops, sorry. Can you try with the latest cvs?
Not at the moment. But I'll try in a few days.
> Your particular problem report was fine, what you have missed is the output
> of t/REPORT which tells us things about your environment. I can't see it
> here
> http://marc.theaimsgroup.com/?l=apache-modperl&m=105968263417468&w=2
Sorry, my deb package dont have the t/ stuff.
[...]
> In any case, have you tried using the snooping filter I was talking about
> in my previous reply? It shows you exactly what's going on inside.
It confirms my problems. Here is output:
>>> connection output filter
o bucket 1: FLUSH []
>>> connection output filter
o bucket 1: FLUSH []
>>> connection output filter
o bucket 1: FLUSH []
>>> connection output filter
o bucket 1: TRANSIENT
[<html><head> TITLE </head><body> BODY</html>]
And here is the code that generates this:
sub handler {
my $r = shift;
$r->content_type('text/html');
$r->print ("<html><head> TITLE </head>");
$r->rflush();
$r->print ("<bo");
$r->rflush();
$r->print ("dy> BODY");
$r->rflush();
$r->print ("</html>");
return Apache::OK;
}
1;
For the record, I am able to cut up a stream nicely using mod_cutup
[1]. This results in something like:
>>> connection output filter
o bucket 1: TRANSIENT
[<html>foo<]
o bucket 2: TRANSIENT
[head><body]
o bucket 3: TRANSIENT
[>
<!-- sd]
o bucket 4: TRANSIENT
[sd -->
[...]
Which at least proves that the snoop filter is working as expected :-)
Anyway, I'll try with the latest mod_perl version as soon as time
allows and post my results later.
[1] http://projects.standblue.net/markive/message.moto?list=apachemodules&ID=771
Re: rflush() not working as documented?
Posted by Stas Bekman <st...@stason.org>.
Martin Wickman wrote:
> Stas Bekman wrote:
>
>>Geoffrey Young wrote:
>>
>>>Martin Wickman wrote:
>>>
>>>>Martin Wickman wrote:
>>>>
>>>>
>>>>>According to docs[1], $r->rflush() should create a new brigade
>>>>>with data. It does not.
>>>
>>>I've seen this also, but was never able to isolate a cause.
>>
>>rflush() works fine, it's possible that the issue with the streaming
>>filter or some other upstream filter that ignores the flush buckets.
>
>
> I doubt that, no other external filter is in use.
>
>
>>Are you using the latest mod_perl 2.0?
>
>
> Nope. I am using 1.99_07. (Btw, that information _was_ included in my
> report, but you trimmed it away:)
oops, sorry. Can you try with the latest cvs?
>>>>This is with:
>>>>Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
>
>
>>It's much appreciated when bug reports are written using the
>>following guidelines:
>>http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
>
>
> Pardon me, but I do believe I supplied enough and accurate information
> -- including relevant, trimmed code snippets and excerpts from apache
> logs in my report.
>
> Except from the fact that I did not build mod_perl myself, I can't
> really see what I missed to include?
Your particular problem report was fine, what you have missed is the output of
t/REPORT which tells us things about your environment. I can't see it here
http://marc.theaimsgroup.com/?l=apache-modperl&m=105968263417468&w=2
>>Martin, please check the mod_perl 2.0 test suite, it has plenty of examples
>>where it used exactly for the reason you've described.
>
>
> Ok, thanks I'll check it out.
>
> I'm guessing that my mod_perl is too old, I like to stay with the
> prebuilt packages (debian) if possible. But if needed, I'll build the
> latest version and test it.
>
> Just thought that someone would know, thats all.
Sure, we just need to know your build env so we can try to reproduce the
problem with a similar one.
In any case, have you tried using the snooping filter I was talking about in
my previous reply? It shows you exactly what's going on inside.
__________________________________________________________________
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: rflush() not working as documented?
Posted by Martin Wickman <ma...@wickman.com>.
Stas Bekman wrote:
>Geoffrey Young wrote:
>>Martin Wickman wrote:
>>>Martin Wickman wrote:
>>>
>>>>According to docs[1], $r->rflush() should create a new brigade
>>>>with data. It does not.
>>
>>I've seen this also, but was never able to isolate a cause.
>
> rflush() works fine, it's possible that the issue with the streaming
> filter or some other upstream filter that ignores the flush buckets.
I doubt that, no other external filter is in use.
> Are you using the latest mod_perl 2.0?
Nope. I am using 1.99_07. (Btw, that information _was_ included in my
report, but you trimmed it away:)
>>>This is with:
>>> Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
> It's much appreciated when bug reports are written using the
> following guidelines:
> http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Pardon me, but I do believe I supplied enough and accurate information
-- including relevant, trimmed code snippets and excerpts from apache
logs in my report.
Except from the fact that I did not build mod_perl myself, I can't
really see what I missed to include?
> Martin, please check the mod_perl 2.0 test suite, it has plenty of examples
> where it used exactly for the reason you've described.
Ok, thanks I'll check it out.
I'm guessing that my mod_perl is too old, I like to stay with the
prebuilt packages (debian) if possible. But if needed, I'll build the
latest version and test it.
Just thought that someone would know, thats all.
Re: rflush() not working as documented?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Martin Wickman wrote:
>
>>
>> Just checking that this did not get lost on the way. Anyone care to
>> give me a hint?
>>
>>
>> On Thu, Jul 31, 2003 at 10:17:06PM +0200, Martin Wickman wrote:
>>
>>> Hello
>>>
>>> According to docs[1], $r->rflush() should create a new brigade with
>>> data. It does not.
>
>
> I've seen this also, but was never able to isolate a cause.
rflush() works fine, it's possible that the issue with the streaming filter or
some other upstream filter that ignores the flush buckets.
Are you using the latest mod_perl 2.0? It's much appreciated when bug reports
are written using the following guidelines:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Martin, please check the mod_perl 2.0 test suite, it has plenty of examples
where it used exactly for the reason you've described.
t/filter/TestFilter/out_bbs_ctx.pm
t/filter/TestFilter/out_str_ctx.pm
t/filter/TestFilter/out_str_declined.pm
t/filter/TestFilter/out_str_remove.pm
If you can break any of these tests, that would be useful.
Otherwise, to debug things use the snooping filter
http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter
I'm planning to release it on CPAN soonish.
__________________________________________________________________
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: rflush() not working as documented?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Martin Wickman wrote:
>
> Just checking that this did not get lost on the way. Anyone care to
> give me a hint?
>
>
> On Thu, Jul 31, 2003 at 10:17:06PM +0200, Martin Wickman wrote:
>
>>Hello
>>
>>According to docs[1], $r->rflush() should create a new brigade with
>>data. It does not.
I've seen this also, but was never able to isolate a cause.
>>
>>It seems the docs and/or my understanding of this is in error.
>>
>>
>>This is with:
>> Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
>>
>>And I am using the streaming filter api.
>>
>>[1] http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers
>>
>>
>>Long version below:
>>------------------
>>
>>I have tried to make my outputfilter clever enough so it can handle
>>being called several times, with tags potentially split between
>>several brigades.
see the code and tests from
http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz
which should give you more ideas about how to code this (and how I tested
long input values)
the corresponding articles might help:
http://www.perl.com/pub/a/2003/04/17/filters.html
http://www.perl.com/pub/a/2003/05/22/testing.html
I've been meaning to chat with stas about the rflush for a while now.
perhaps we can prioritize it :)
--Geoff
Re: rflush() not working as documented?
Posted by Martin Wickman <ma...@wickman.com>.
Just checking that this did not get lost on the way. Anyone care to
give me a hint?
On Thu, Jul 31, 2003 at 10:17:06PM +0200, Martin Wickman wrote:
> Hello
>
> According to docs[1], $r->rflush() should create a new brigade with
> data. It does not.
>
> It seems the docs and/or my understanding of this is in error.
>
>
> This is with:
> Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
>
> And I am using the streaming filter api.
>
> [1] http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers
>
>
> Long version below:
> ------------------
>
> I have tried to make my outputfilter clever enough so it can handle
> being called several times, with tags potentially split between
> several brigades.
>
> Now I would like to test this somehow (ie, force mod_perl to call my
> filter several times). I tried using $r->rflush(), but cannot get it
> to work as I and the docs would expect.
>
> I tried creating a ResponseHandler which explicitly breaks some silly
> html data into brigades:
>
> sub handler {
> my $r = shift;
> $r->content_type('text/html');
> $r->log_error ("Cutting");
> $r->print ("<html><head> title </head>"); $r->rflush();
> $r->print ("<bo"); $r->rflush();
> $r->print ("dy> body "); $r->rflush();
> $r->print ("</html>");
> $r->log_error ("Cutting: end");
> return Apache::OK;
> }
>
> And then a simple 'DebugFilter' output filter which just prints each chunk:
>
> sub handler : FilterRequestHandler {
> my $f = shift;
> $f->r->log_error ("DebugFilter called");
> $f->print ("DebugFilter called\n");
> while ($f->read(my $buffer, 1024)) {
> $f->print("CHUNK:$buffer:CHUNK\n");
> }
> return Apache::OK;
> }
>
> And httpd.conf
>
> <Location /test/>
> PerlResponseHandler MyApache::Cutter
> PerlOutputFilterHandler MyApache::DebugFilter
> </Location>
>
> When I run this, I see that DebugFilter gets called 4 times (3
> rflush's + 1 eos or something). But the strange thing is that only the
> _last_ call contains data. That data is _everything_ nicely
> concatenated and not splitted as I would guess.
>
> Here is actual output:
>
> $ wget --quiet -O - http://localhost/test/
> DebugFilter called
> DebugFilter called
> DebugFilter called
> DebugFilter called
> CHUNK:<html><head> title </head><body> body </html>:CHUNK
>
> And the error_log:
>
> [Thu Jul 31 21:52:42 2003] [error] Cutting: start
> [Thu Jul 31 21:52:42 2003] [error] DebugFilter called
> [Thu Jul 31 21:52:42 2003] [error] DebugFilter called
> [Thu Jul 31 21:52:42 2003] [error] DebugFilter called
> [Thu Jul 31 21:52:42 2003] [error] Cutting: end
> [Thu Jul 31 21:52:42 2003] [error] DebugFilter called