Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <43BD99A5.6080507@apache.org>
Date: Thu, 05 Jan 2006 23:11:49 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: mod_proxy vs. serverpush
References: <NEBBKFBOLKOHMEOJLLLHAEHKFIAA.matthias.behrens@gulp.de>
 <43BD7BBE.10103@sharp.fm> <43BD8130.7060903@apache.org>
 <43BD8EE1.3010804@sharp.fm>
In-Reply-To: <43BD8EE1.3010804@sharp.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


On 01/05/2006 10:25 PM, Graham Leggett wrote:
> Ruediger Pluem wrote:
> 

[..cut..]

>> Anyway, it does not work as expected, as it seems that the condition
>> (APR_STATUS_IS_EAGAIN(rv)
>>                         || (rv == APR_SUCCESS &&
>> APR_BRIGADE_EMPTY(bb))) {
>> never gets true.
> 
> 
> I think this if statement covers the case where a non blocking read is
> attempted, and zero bytes are returned, in which case another non
> blocking read might also return zero bytes, causing the loop to spin at
> 100% processor usage.
> 
> The problem lies in the code further down:
> 
>                     /* try send what we read */
>                     if (ap_pass_brigade(r->output_filters, bb) !=
> APR_SUCCESS
>                         || c->aborted) {
>                         /* Ack! Phbtt! Die! User aborted! */
>                         backend->close = 1;  /* this causes socket close
> below *
> /
>                         finish = TRUE;
>                     }

No, I do not think so from the original idea. From my point of view the typical situation
on the backend that wants to flush some data is:

1. It sends some data.
2. It does no send any more data for a while.

If the condition would work as I expect, then all data from the backend is read (maybe in
several loop iterations and thus passed down the filter chain already by the code you mention above).
Then the backend would stop sending data for some time causing the condition to become true.
This would cause the code to add a flush bucket and pass the brigade down the filter chain.


> 
> Without explicitly adding flush buckets to the output filter stack, the
> output filter stack seems to buffer before sending (rational behaviour).
> 
> To change this, we would need to add an output flush bucket after each
> read.

I do not think that this a good idea. It leads to too much traffic overhead. Basicly I like
the idea: Read from the backend as long as data is present (non-blocking). If no more data
is present flush filter chain and switch to blocking mode to wait for further data.

Regards

R�diger