Geoffrey Young wrote:


Stas Bekman wrote:

Craig Shelley wrote:

I'll take a look at it. But you didn't supply a complete bug report as explained http://perl.apache.org/bugs/. Please do so.


I think I've got this figured out.

the problem is with the r->main logic in mpxs_ap_run_sub_req.

with that logic, what ends up happening is that the data currently being operated on is explicity flushed. this is bad within a (streaming) filter where you are expected to call $f->print yourself, as the data is sent without your permission (you may be operating on it or not want to send it at all). it also seemed to cause infinite loop in my tests because the filter was seeing the same data over and over again.

I can't really understand the reason behind the code anyway, since I can't see anywhere in core where such logic is applied before ap_run_sub_request - everyone seems to call without regard to where in the data stream they happen to be, so I don't get why mod_perl should be any different. indeed commenting it out fixes the problem for me.

however, removing that logic causes api/lookup_uri2.t to fail, but I suspect this is an issue with puts() rather than the subrequest mechanism - changing puts() to print() makes everything work just fine. does puts() write directly to the wire, bypassing filters?

Sorry, but that's cheating ;)


rputs() never flushes data,
print() flushes if $| == 1;

Please don't remove rputs, it's there for a reason.

If you fix lookup_uri2's handler to be:

sub handler {
    my $r = shift;

subrequest($r, 'myplan');

    local $| = 0;
    $r->print("ok 2\n");

subrequest($r, 'ok3');

    Apache::OK;
}

You get:

ok 1
ok 3
ok 2
Confused test output: test 3 answered after test 3
ok

which is wrong.

So there is no problem with the r->main logic in mpxs_ap_run_sub_req, it's there for exactly this reason.

I wonder why $| is on? must have forgotten to localize $| setting somewhere.

anyway, attached is a patch against current cvs - fixes and a few filtering subrequest tests. note that the patch does not mention the removal of xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer needed, so I guess you should remove that file by hand before compiling.

craig - note that this patch affects the autogenerated code, so in order to get it to work you'll need to apply it, then run make realclean, perl Makefile.PL, etc.

and you forgot to add to the patch a new file #t/htdocs/filter/subrequest.txt core subrequest

regarding new tests, do you mind calling them:

out_str_subreq_core
out_str_subreq_perl

since 'sub' is too confusing, or even better:

out_str_subreq_default
out_str_subreq_modperl

since these correspond to the SetHandler settings.

Thanks.
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Reply via email to