Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: Dev

Next Release

 

 

ModPerl dev RSS feed   Index | Next | Previous | View Threaded


pgollucci at p6m7g8

Sep 25, 2005, 9:19 PM

Post #1 of 20 (3339 views)
Permalink
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 <4327DBC5.8050700[at]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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


stas at stason

Sep 26, 2005, 3:51 PM

Post #2 of 20 (3280 views)
Permalink
Re: Next Release [In reply to]

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 <4327DBC5.8050700[at]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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


tom.schindl at bestsolution

Sep 27, 2005, 1:45 AM

Post #3 of 20 (3276 views)
Permalink
Re: Next Release [In reply to]

-----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 <4327DBC5.8050700[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Sep 27, 2005, 7:28 AM

Post #4 of 20 (3278 views)
Permalink
Re: Next Release [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Sep 30, 2005, 8:48 PM

Post #5 of 20 (3297 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Sep 30, 2005, 8:54 PM

Post #6 of 20 (3275 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


stas at stason

Oct 3, 2005, 10:46 PM

Post #7 of 20 (3267 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


stas at stason

Oct 3, 2005, 11:20 PM

Post #8 of 20 (3261 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


tom.schindl at bestsolution

Oct 4, 2005, 8:05 AM

Post #9 of 20 (3261 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

-----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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Oct 4, 2005, 9:22 AM

Post #10 of 20 (3263 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


stas at stason

Oct 4, 2005, 9:25 AM

Post #11 of 20 (3273 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Oct 4, 2005, 9:35 AM

Post #12 of 20 (3257 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


tom.schindl at bestsolution

Oct 4, 2005, 10:01 AM

Post #13 of 20 (3277 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

-----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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


stas at stason

Oct 4, 2005, 10:45 AM

Post #14 of 20 (3264 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


stas at stason

Oct 4, 2005, 10:47 AM

Post #15 of 20 (3272 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Oct 4, 2005, 11:46 AM

Post #16 of 20 (3254 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Oct 4, 2005, 11:54 AM

Post #17 of 20 (3251 views)
Permalink
Re: $|, flushing, etc... [was Next Release] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Oct 30, 2005, 10:08 PM

Post #18 of 20 (3216 views)
Permalink
Re: PerlIOApache_flush() [was $|, flushing, etc... [was Next Release]] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org


pgollucci at p6m7g8

Oct 30, 2005, 10:59 PM

Post #19 of 20 (3205 views)
Permalink
Re: PerlIOApache_flush() [was $|, flushing, etc... [was Next Release]] [In reply to]

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[at]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
Attachments: debug_log (7.04 KB)


stas at stason

Oct 30, 2005, 11:52 PM

Post #20 of 20 (3217 views)
Permalink
Re: PerlIOApache_flush() [was $|, flushing, etc... [was Next Release]] [In reply to]

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[at]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[at]perl.apache.org
For additional commands, e-mail: dev-help[at]perl.apache.org

ModPerl dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.