httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <rede...@remulak.net>
Subject Re: Patch mod_proxy: mod_proxy + mod_cache problem
Date Mon, 23 Sep 2002 15:36:05 GMT


Matthieu Estrade wrote:

In a previous note you explained:

> on the file not cached because the MaxStreamingBuffer error, the code above never detect
a EOS bucket, so, it return a size to the following code:

> if (!all_bucket_here){
> if (unresolved_length || size > MaxStreamingBuffer)
> exit with MaxStreamingBuffer Error.
> }



If it entered into this chunk of code then the cache code either:
1) encountered a bucket with an unresolved length (like a socket bucket)  or
2) the cumulative length of all buckets/brigades encountered so far was greater
      then the value of MaxStreamingBuffer.

If the program goes into this branch of code it will remove the cache filter
from teh filter chain. This is why the cache code is not looking at any of
the subsequent brigades. Cache has already determined that it has no reason
to look at them.

If this is happening due to exceeding MaxStreamingBuffer, try setting the
value to something higher and see if it works for you. If it is encountering
a bucket with an unresolved length then there is nothing that can be done.
That type of bucket cannot be cached.

Proxy is working the way it should.

 >

> Hi Paul,
> 
> I know about mod_cache is only working on one brigade, but my problem is 
> not here.
> My problem is i can't setup the filter cache_in_filter to be executed 
> after mod_proxy pass his "last" brigade to the filter chain
> Actually, mod_cache_filter_in is executed only one time when mod_proxy 
> have passed the "first" brigade to the output_filters.
> So the others brigade containing data are not available.
> 
> so, have i to consider that cache_filter_in will have to be able to 
> cache document in many times process,
> Or is it possible to think that the cache_filter could be placed when 
> mod_proxy finished to pass the "last" brigade,
> reading all the brigade and cache it ?
> 
> regards,
> 
> Matthieu
> 
> Paul J. Reder wrote:
> 
>> Actually, the problem is in the fact that there is more than one
>> brigade and the cache code can't currently handle that.
>>
>> Proxy is working the way it is supposed to. This allows Apache
>> to process large responses without having to buffer the whole
>> thing inside Apache. Apache uses less memory, and the user starts
>> seeing results sooner. If proxy were to process all of the
>> brigades of a large response before the next filter were allowed
>> access, then proxy could potentially buffer a *huge* amount of
>> data.
>>
>> The answer is that the cache code currently only caches responses
>> that arrive in one brigade. Proxy isn't the problem.
>>
>> Matthieu Estrade wrote:
>>
>>> Hi graham,
>>>
>>> the problem is the filter is called between two ap_pass_brigade by 
>>> the reverse proxy...
>>> like:
>>>
>>> proxy:
>>> get_brigade (data from backend)
>>> pass_brigade(pass data to outputfilter)
>>> cache_filter
>>> get_brigade(data from backend)
>>> pass_brigade(pass_data_to outputfilter)
>>>
>>> on one response by the backend server.
>>>
>>> regards,
>>> Matthieu
>>>
>>> Graham Leggett wrote:
>>>
>>>> Matthieu Estrade wrote:
>>>>
>>>>> I agree with you about the proxy...
>>>>> Do you think it's possible to force the cache filter, be runned 
>>>>> after all the proxy filters ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The cache filter is supposed to run after all the filters for 
>>>> maximum caching advantage.
>>>>
>>>> Regards,
>>>> Graham
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 


-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein



Mime
View raw message