You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philip M. Gollucci" <pg...@p6m7g8.com> on 2005/09/26 06:19:46 UTC
Next Release
Hi,
I'm thinking I'll roll the first release candidate between Thursday->Saturday
comming up. If anyone has anything they want in it, please let me know or
commit it before then.
I've got one A-T pending some thought first and Stas' suggest:
Re: mp2biug and httpd TestConfigData <43...@p6m7g8.com>
Next question, I'm going to release A-T and mp2 or just mp2?
I would assume both?
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> recompile yada yada
>
> mp2_trace - flush.cgi under ModPerl::RegistryBB (NOW WORKS)
> mp2_api_trace - flush2.cgi ModPerl::RegistryBB
Appologies, this very last set should have been mp2_trace_patched and mp2_api_trace_patched
D'oh!
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stas Bekman wrote:
> No, since it's not a regression. It's really up to you as an RM to
> decide. My advice is to release things as they are, then fix this
> problem and give it some time to be tested before it gets into the next
> release.
Agreed. If I've got enough postive feedback, I'll release on Sunday when I'm back from LA or I'll roll RC2.
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Stas Bekman <st...@stason.org>.
Philip M. Gollucci wrote:
> Stas Bekman wrote:
>
>> Thinking more about it we need a better fix. Currently
>> modperl_wbucket_flush is not flexible enough. What PerlIOApache_flush
>> needs is:
>>
>> - if there is data to flush, flush it and *unconditionaly* append the
>> flush bucket
>> - if there is no data to flush do nothing.
>>
>> modperl_wbucket_flush itself needs to have the other two cases that it
>> supports now.
>
> Does this qualify as showstopper ?
No, since it's not a regression. It's really up to you as an RM to decide.
My advice is to release things as they are, then fix this problem and give
it some time to be tested before it gets into the next release.
--
_______________________________________________________________
Stas Bekman mailto:stas@stason.org | http://stason.org/
MailChannels: Assured Messaging (TM) | http://mailchannels.com/
The "Practical mod_perl" book | http://modperlbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stas Bekman wrote:
> Thinking more about it we need a better fix. Currently
> modperl_wbucket_flush is not flexible enough. What PerlIOApache_flush
> needs is:
>
> - if there is data to flush, flush it and *unconditionaly* append the
> flush bucket
> - if there is no data to flush do nothing.
>
> modperl_wbucket_flush itself needs to have the other two cases that it
> supports now.
Does this qualify as showstopper ?
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Tom Schindl <to...@bestsolution.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]
>
> Sorry Tom, I have not read that question, I still have tons of emails to
> catch up with. Ideally, send here a new test that fails and we will be
> much quicker to look at it/fix it.
>
Sorry I cann't it's not a problem of mine. I only brought it to the dev
list because I thought maybe some should look at it, which Philip did
eventually.
>> We should at least document the behaviour? I'd generate a fix for the
>> docs if my assumption is correct.
>
>
>
>
Tom
- --
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
- ------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSE mobile ++43 676 3232147
- ------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833
http://www.bestsolution.at phone ++43 512 935834
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFDQrVy4E2ESUTeSPQRAn9hAJ9vtbwHhQvjnrllcPRpcCUCnBsi3QCePzUj
paqh+oI+X+rHf4JYJzgCMWw=
=U2MN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Stas Bekman <st...@stason.org>.
Tom Schindl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stas Bekman wrote:
>
>>Stas Bekman wrote:
>>
>>
>>>Philip M. Gollucci wrote:
>>>[...]
>>>
>>>
>>>>6. Okay so from the 4 above attached files in #5 it looks like
>>>>PerlIOApache_flush() is being called, but not working.
>>>> [I'll list this function at the end of the e-mail.]
>>>> Basically, I think there is a SNAFU here
>>>>
>>>>MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE), ":Apache2
>>>>IO flush");
>>>>
>>>>That FALSE ends up being add_flush_bucket so even though we call
>>>>flush we never get a flush bucket!!!!!!
>>>
>>>
>>>
>>>I think your observation and the fix are correct Philip. But before we
>>>commit any fix we need to have a test that breaks and the fix fixes it.
>>
>>
>>As I think more about it, there was a reason for this FALSE setting. As
>>you know Apache will send headers as soon as it gets some data out and a
>>flush bucket is by Apache-talk is data. So what was happening is that
>>when users were doing something in their code that was causing perl to
>>flush STDOUT behind the scenes (like a filehandle dup), Apache will go
>>and generate the headers even if the user haven't had a chance to set
>>those. That's why it was written in such a way: i.e. add a flush bucket
>>only if there is some data to flush, otherwise you need to call
>>$r->flush if you want the flush to be sent anyway.
>>
>
> Stas if I get you right you say that the actual behaviour of "undef $|"
> is desired and not a failure (I can somehow remember now the discussion)
Thinking more about it we need a better fix. Currently
modperl_wbucket_flush is not flexible enough. What PerlIOApache_flush
needs is:
- if there is data to flush, flush it and *unconditionaly* append the
flush bucket
- if there is no data to flush do nothing.
modperl_wbucket_flush itself needs to have the other two cases that it
supports now.
a quick temp fix would be:
Index: src/modules/perl/modperl_io_apache.c
===================================================================
--- src/modules/perl/modperl_io_apache.c (revision 293536)
+++ src/modules/perl/modperl_io_apache.c (working copy)
@@ -170,9 +170,11 @@
rcfg->wbucket->outbuf,
rcfg->wbucket->outcnt));
- MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE),
- ":Apache2 IO flush");
-
+ if (rcfg->wbucket->outcnt) {
+ MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, TRUE),
+ ":Apache2 IO flush");
+ }
+
return 0;
}
I think this is the desired behavior. We need a test for this case. Does
it do the trick? If so, then modperl_wbucket_flush needs more work (that
if() doesn't belong here, but to modperl_wbucket_flush.
> I didn't get an answer when I asked if $r->flush does what the user
> wanted too. Maybe I should ask again I've been only guessing.
Sorry Tom, I have not read that question, I still have tons of emails to
catch up with. Ideally, send here a new test that fails and we will be
much quicker to look at it/fix it.
> We should at least document the behaviour? I'd generate a fix for the
> docs if my assumption is correct.
--
_______________________________________________________________
Stas Bekman mailto:stas@stason.org | http://stason.org/
MailChannels: Assured Messaging (TM) | http://mailchannels.com/
The "Practical mod_perl" book | http://modperlbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Tom Schindl <to...@bestsolution.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stas Bekman wrote:
> Stas Bekman wrote:
>
>> Philip M. Gollucci wrote:
>> [...]
>>
>>> 6. Okay so from the 4 above attached files in #5 it looks like
>>> PerlIOApache_flush() is being called, but not working.
>>> [I'll list this function at the end of the e-mail.]
>>> Basically, I think there is a SNAFU here
>>>
>>> MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE), ":Apache2
>>> IO flush");
>>>
>>> That FALSE ends up being add_flush_bucket so even though we call
>>> flush we never get a flush bucket!!!!!!
>>
>>
>>
>> I think your observation and the fix are correct Philip. But before we
>> commit any fix we need to have a test that breaks and the fix fixes it.
>
>
> As I think more about it, there was a reason for this FALSE setting. As
> you know Apache will send headers as soon as it gets some data out and a
> flush bucket is by Apache-talk is data. So what was happening is that
> when users were doing something in their code that was causing perl to
> flush STDOUT behind the scenes (like a filehandle dup), Apache will go
> and generate the headers even if the user haven't had a chance to set
> those. That's why it was written in such a way: i.e. add a flush bucket
> only if there is some data to flush, otherwise you need to call
> $r->flush if you want the flush to be sent anyway.
>
Stas if I get you right you say that the actual behaviour of "undef $|"
is desired and not a failure (I can somehow remember now the discussion)
I didn't get an answer when I asked if $r->flush does what the user
wanted too. Maybe I should ask again I've been only guessing.
We should at least document the behaviour? I'd generate a fix for the
docs if my assumption is correct.
> I think we may even have a test for that case (grep for $| I guess)
>
- --
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
- ------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSE mobile ++43 676 3232147
- ------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833
http://www.bestsolution.at phone ++43 512 935834
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFDQppA4E2ESUTeSPQRAtBMAJ93rve1at71VwmQHbPcu5Yk1WVMkQCeNDzQ
C3ufx1N4URZjehCpcgWg2AI=
=JwLV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIOApache_flush() [was $|, flushing, etc... [was Next Release]]
Posted by Stas Bekman <st...@stason.org>.
Philip M. Gollucci wrote:
> Philip M. Gollucci wrote:
>
>> Stas Bekman wrote:
>> > and if you try my last patch suggestion?
>>
>> Hi, yikes, I'm behind.... Anyway, I finally got around to trying this.
>> Same result as without. Hopefully, at some point during the week,
>> I'll be able to turn on tracing and the like and see why nothing changed.
>
>
> Well, I turned on Apache2::DebugFilter and PerlTrace fo again. The
> output is correct as in flush buckets are now sent when they should be,
> but if I visually look at the browser, nothing shows up until the end.
>
> Something is still buffering the data.
I'd have suggested to push that debug filter just before the "CORE" output
filter, so you could check that some other filter on the way doesn't
misbehave and ignores our FLUSH bucket, but Apache's API won't let you
easily do that at run-time. It's probably do-able in C. something like:
for (f = c->input_filters; f; f = f->next) {
if (strcasecmp(f->frec->name, "CORE") == 0) {
f->frec->filter_func.in_func = my_core_output_filter;
break;
}
}
and have that filter do some debugging and call the original CORE filter.
In perl you can just remove the filter:
for (my $ff = $f->r->connection->output_filters; $ff;
$ff = $ff->next) {
if ($ff->frec->name eq 'CORE') {
$ff->remove;
last;
}
}
but can't substitute or inject a new one, which is what we are after. But
I think we could extend the API to allow injecting new perl filters. That
would be handy.
So it's probably the easiest to modify the CORE filter core_output_filter
in apache sources to dump the debug info like Apache2::DebugFilter does.
Check httpd-2.0/.gdbinit for the code that dumps brigades.
--
_____________________________________________________________
Stas Bekman mailto:stas@stason.org http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIOApache_flush() [was $|, flushing, etc... [was Next Release]]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Stas Bekman wrote:
> > and if you try my last patch suggestion?
>
> Hi, yikes, I'm behind.... Anyway, I finally got around to trying this.
> Same result as without. Hopefully, at some point during the week, I'll
> be able to turn on tracing and the like and see why nothing changed.
Well, I turned on Apache2::DebugFilter and PerlTrace fo again. The output is
correct as in flush buckets are now sent when they should be, but if I visually
look at the browser, nothing shows up until the end.
Something is still buffering the data.
error_log is attached.
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
Re: PerlIOApache_flush() [was $|, flushing, etc... [was Next Release]]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stas Bekman wrote:
> and if you try my last patch suggestion?
Hi, yikes, I'm behind.... Anyway, I finally got around to trying this.
Same result as without. Hopefully, at some point during the week, I'll be able
to turn on tracing and the like and see why nothing changed.
svn diff
Index: src/modules/perl/modperl_io_apache.c
===================================================================
--- src/modules/perl/modperl_io_apache.c (revision 329512)
+++ src/modules/perl/modperl_io_apache.c (working copy)
@@ -170,8 +170,10 @@
rcfg->wbucket->outbuf,
rcfg->wbucket->outcnt));
- MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE),
- ":Apache2 IO flush");
+ if (rcfg->wbucket->outcnt) {
+ MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, TRUE),
+ ":Apache2 IO flush");
+ }
return 0;
}
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stas Bekman wrote:
> and if you try my last patch suggestion?
I'll try to give this a whirl late tonight.
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Stas Bekman <st...@stason.org>.
Philip M. Gollucci wrote:
> Stas Bekman wrote:
>
>> As I think more about it, there was a reason for this FALSE setting.
>> As you know Apache will send headers as soon as it gets some data out
>> and a flush bucket is by Apache-talk is data. So what was happening is
>> that when users were doing something in their code that was causing
>> perl to flush STDOUT behind the scenes (like a filehandle dup), Apache
>> will go and generate the headers even if the user haven't had a chance
>> to set those. That's why it was written in such a way: i.e. add a
>> flush bucket only if there is some data to flush, otherwise you need
>> to call $r->flush if you want the flush to be sent anyway.
>
> Yes, it breaks scanhdrs2.t by setting it to TRUE.
and if you try my last patch suggestion?
--
_______________________________________________________________
Stas Bekman mailto:stas@stason.org | http://stason.org/
MailChannels: Assured Messaging (TM) | http://mailchannels.com/
The "Practical mod_perl" book | http://modperlbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stas Bekman wrote:
> As I think more about it, there was a reason for this FALSE setting. As
> you know Apache will send headers as soon as it gets some data out and a
> flush bucket is by Apache-talk is data. So what was happening is that
> when users were doing something in their code that was causing perl to
> flush STDOUT behind the scenes (like a filehandle dup), Apache will go
> and generate the headers even if the user haven't had a chance to set
> those. That's why it was written in such a way: i.e. add a flush bucket
> only if there is some data to flush, otherwise you need to call
> $r->flush if you want the flush to be sent anyway.
Yes, it breaks scanhdrs2.t by setting it to TRUE.
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Philip M. Gollucci wrote:
> [...]
>
>> 6. Okay so from the 4 above attached files in #5 it looks like
>> PerlIOApache_flush() is being called, but not working.
>> [I'll list this function at the end of the e-mail.]
>> Basically, I think there is a SNAFU here
>>
>> MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE), ":Apache2 IO
>> flush");
>>
>> That FALSE ends up being add_flush_bucket so even though we call flush
>> we never get a flush bucket!!!!!!
>
>
> I think your observation and the fix are correct Philip. But before we
> commit any fix we need to have a test that breaks and the fix fixes it.
As I think more about it, there was a reason for this FALSE setting. As
you know Apache will send headers as soon as it gets some data out and a
flush bucket is by Apache-talk is data. So what was happening is that when
users were doing something in their code that was causing perl to flush
STDOUT behind the scenes (like a filehandle dup), Apache will go and
generate the headers even if the user haven't had a chance to set those.
That's why it was written in such a way: i.e. add a flush bucket only if
there is some data to flush, otherwise you need to call $r->flush if you
want the flush to be sent anyway.
I think we may even have a test for that case (grep for $| I guess)
--
_______________________________________________________________
Stas Bekman mailto:stas@stason.org | http://stason.org/
MailChannels: Assured Messaging (TM) | http://mailchannels.com/
The "Practical mod_perl" book | http://modperlbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by Stas Bekman <st...@stason.org>.
Philip M. Gollucci wrote:
[...]
> 6. Okay so from the 4 above attached files in #5 it looks like
> PerlIOApache_flush() is being called, but not working.
> [I'll list this function at the end of the e-mail.]
> Basically, I think there is a SNAFU here
>
> MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE), ":Apache2 IO
> flush");
>
> That FALSE ends up being add_flush_bucket so even though we call flush
> we never get a flush bucket!!!!!!
I think your observation and the fix are correct Philip. But before we
commit any fix we need to have a test that breaks and the fix fixes it.
> However, this needs to be conditionalized on $| which I've no
> idea how to test for in XS yet.
Oh the joys of perl guts. Assuming that you work on the selected gv, the
check would be:
(IoFLAGS(GvIOp(PL_defoutgv)) & IOf_FLUSH)
for more walk around doio.c perlio.c and similar files in the perl source
code. Let me know if you need more help.
However I'm not sure why do you need that. I think PerlIOApache_flush
shouldn't be called if $| is not true in first place.
--
_______________________________________________________________
Stas Bekman mailto:stas@stason.org | http://stason.org/
MailChannels: Assured Messaging (TM) | http://mailchannels.com/
The "Practical mod_perl" book | http://modperlbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $|, flushing, etc... [was Next Release]
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Tom Schindl wrote:
> Could someone please clarify this problem before releasing:
> http://www.gossamer-threads.com/lists/modperl/modperl/84625?nohighlight=1#84625
I'm probably going to screw up the way I say this, but here we go.
All files (11) mentioned are available here:
http://p6m7g8.net/MP2/84625
1. perl 5.8.7 w/out ithreads with PerlIO / apache 2.0.54 apr not threaded / mp2-svn
2. install Apache2::DebugFilter from CPAN
3. 2 test scripts:
first uses print
you can run me under cgi and mp2 / registry
second use $r->print
you can run me under mp2 registry
4. 3 runs of this script with the following configs in httpd.conf
PerlModule Apache2::DebugFilter
PerlOutputFilterHandler Apache2::DebugFilter::snoop_connection
Alias /perl-bb/ /usr/home/pgollucci/httpd/2.0.54/prefork/perl-bb/
<Location /perl-bb/>
SetHandler perl-script
PerlResponseHandler ModPerl::RegistryBB
Options +ExecCGI
Allow from all
</Location>
cgi_log - flush.cgi run under mod_cgi (works as expected)
mp2_log - flush.cgi run under ModPerl::RegistryBB (doesn't work as expected)
mp2_api - flush2.cgi run under ModPerl::RegistryBB (works as expected)
You can clearly see that the FLUSH buckets don't get sent in the mp2_log.
Some reading first
http://perl.apache.org/docs/2.0/api/Apache2/RequestIO.html#C_rflush_
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
http://perl.apache.org/docs/2.0/user/coding/coding.html#Generating_HTTP_Response_Headers
5. pradeep.smani at gmai
http://www.gossamer-threads.com/lists/modperl/modperl/84625?nohighlight=1#84625
found the right underlying function here modperl_wbucket_pass()
I can illustrate this by turning off the Apache2::Debug configs above
and enabling tracing assuming I turned it on via MP_TRACE=1 in the Makefile.PL step.
So to httpd.conf I add
PerlTrace fo
[Thats filter and I/O Tracing]
[there is no tracing of filters under mod_cgi]
mp2_trace - flush.cgi under ModPerl::RegistryBB
mp2_api_trace - flush2.cgi ModPerl::RegistryBB
mp2_trace_0 - flush.cgi under ModPerl::RegistryBB $|= 0
mp2_api_trace_0 - flush2.cgi under ModPerl::RegistryBB $|= 0
RE:84625
The reason why seeting the add_flush_bucket variable "fixes" this is because it adds a FLUSH bucket to the
output bucket brigade (you can see these were "missing" in the files from #4). This variable is set
in modperl_filter.c:get_bucket(modperl_filter_t *filter)
in
else if (MP_FILTER_IS_FLUSH(filter)) {
MP_TRACE_f(MP_FUNC, MP_FILTER_NAME_FORMAT
"read in: FLUSH bucket\n",
MP_FILTER_NAME(filter->f));
filter->flush = 1;
return 0;
}
6. Okay so from the 4 above attached files in #5 it looks like PerlIOApache_flush() is being called, but not working.
[I'll list this function at the end of the e-mail.]
Basically, I think there is a SNAFU here
MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE), ":Apache2 IO flush");
That FALSE ends up being add_flush_bucket so even though we call flush we never get a flush bucket!!!!!!
Apply this diff
Index: modperl_io_apache.c
===================================================================
--- modperl_io_apache.c (revision 292912)
+++ modperl_io_apache.c (working copy)
@@ -170,7 +170,7 @@
rcfg->wbucket->outbuf,
rcfg->wbucket->outcnt));
- MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE),
+ MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, TRUE),
":Apache2 IO flush");
return 0;
recompile yada yada
mp2_trace - flush.cgi under ModPerl::RegistryBB (NOW WORKS)
mp2_api_trace - flush2.cgi ModPerl::RegistryBB
However, this needs to be conditionalized on $| which I've no idea how to test for in XS yet. Also, this sends
a separate bucket briade (bb) with just a FLUSH bucket. This case is avoided because of the extra
overhead. FYI, the test suite still passes with this. I'm not quite sure how though, I thought sure it should
have broken some of the header parsing.
I have don't think this is the correct solution, more likely, I think this might be a bug in PerlIO Layers in
PERL itself?
HTH
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Next Release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Tom Schindl wrote:
> Could someone please clarify this problem before releasing:
>
> http://www.gossamer-threads.com/lists/modperl/modperl/84625?nohighlight=1#84625
I'll tack it on my todo list....
--
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Next Release
Posted by Tom Schindl <to...@bestsolution.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Could someone please clarify this problem before releasing:
http://www.gossamer-threads.com/lists/modperl/modperl/84625?nohighlight=1#84625
Tom
Stas Bekman wrote:
> Philip M. Gollucci wrote:
>
>> Hi,
>>
>> I'm thinking I'll roll the first release candidate between
>> Thursday->Saturday comming up. If anyone has anything they want in
>> it, please let me know or commit it before then.
>>
>> I've got one A-T pending some thought first and Stas' suggest:
>> Re: mp2biug and httpd TestConfigData <43...@p6m7g8.com>
>>
>> Next question, I'm going to release A-T and mp2 or just mp2?
>>
>> I would assume both?
>
>
> Yes, we always need to release both, even if A-T had no changes since
> last version. See the RELEASE files in both dirs for details. Don't
> hesitate to ask questions if you have any, Philip.
>
- --
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
- ------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSE mobile ++43 676 3232147
- ------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833
http://www.bestsolution.at phone ++43 512 935834
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFDOQaM4E2ESUTeSPQRAoU/AJ0eYWCPx5QCXczFc+sOIO87UzcakgCeI9cY
4PaN+W0HYICgoYojuIMhmrU=
=oBT1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Next Release
Posted by Stas Bekman <st...@stason.org>.
Philip M. Gollucci wrote:
> Hi,
>
> I'm thinking I'll roll the first release candidate between
> Thursday->Saturday comming up. If anyone has anything they want in it,
> please let me know or commit it before then.
>
> I've got one A-T pending some thought first and Stas' suggest:
> Re: mp2biug and httpd TestConfigData <43...@p6m7g8.com>
>
> Next question, I'm going to release A-T and mp2 or just mp2?
>
> I would assume both?
Yes, we always need to release both, even if A-T had no changes since last
version. See the RELEASE files in both dirs for details. Don't hesitate to
ask questions if you have any, Philip.
--
_______________________________________________________________
Stas Bekman mailto:stas@stason.org | http://stason.org/
MailChannels: Assured Messaging (TM) | http://mailchannels.com/
The "Practical mod_perl" book | http://modperlbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org