Forcing order of perl output filters

--0-1910053665-1209394485=:99483
Content-Type: text/plain; charset=us-ascii

I have the following configuration in a PerlFixupHandler,

$r->add_config([
'PerlOutputFilterHandler BI::Apache::FilterBeforeIncludes',
'PerlSetOutputFilter INCLUDES',
'PerlOutputFilterHandler BI::Apache::FilterAfterIncludes']);

I want the response to be processed by the filters in the order specified in the configruation as shown above. However for SOME reqeusts, the second handler, FilterAfterIncludes, is initiated before the first one finishes. The second handler to work properly it should start just after the first one because it expects some shared variable that is set by the first handler. It appears that this happens when the size of the response is big, is there any other way of forcing the order?

Thanks
Woinshet


Environment:

Red Hat Enterprise Linux
Apache/2.0.46
perl, v5.8.0


____________________________________________________________ ________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--0-1910053665-1209394485=:99483
Content-Type: text/html; charset=us-ascii

Re: Forcing order of perl output filters

On Mon 28 Apr 2008, woinshet abdella wrote:
> $r->add_config([
> 'PerlOutputFilterHandler BI::Apache::FilterBeforeIncludes',
> 'PerlSetOutputFilter INCLUDES',
> 'PerlOutputFilterHandler BI::Apache::FilterAfterIncludes']);
> =A0
> I want the response to be processed by the filters in the order specified
> in the configruation as shown above. However for SOME reqeusts, the second
> handler, FilterAfterIncludes, is initiated before the first one finishes.
> The second handler to work properly it should start just after the first
> one because it expects some shared variable that is set by the first
> handler. It appears that this happens when the size of the response is bi=
g,
> is there any other way of forcing the order?

This is how filters work, no surprise. A filter is normally called multiple=
=20
times per request. Each time it processes a chunk of the output as it goes=
=20
down the output chain. When one filter has processed the chunk it is passed=
=20
to the next filter until it is eventually sent out on the wire. Then the ne=
xt=20
chunk does the same. So you cannot expect one filter to see the complete=20
output before another one is started.

You can of course do some tricks like catching the whole output in the firs=
t=20
filter throwing the buckets away. Then at end of stream you can reinsert th=
e=20
stuff. But that is quite complex. If you decide to go this way remember not=
=20
to cache the stuff in RAM but to write it to file(s). Otherwise your=20
processes will waste a lot of memory.

Torsten

=2D-
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net