On 04/28/2016 02:40 AM, Yann Ylavic wrote:
> On Wed, Apr 27, 2016 at 7:28 AM, Stefan Eissing
> wrote:
>>
>>
>>> Am 26.04.2016 um 23:57 schrieb Yann Ylavic :
>>>
>>> On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing
>>> wrote:
Today I Learned the difference between writing
DATA + META
>
tl;dr
It seems that the core filter does things correctly and my reading of the code
was wrong. Thanks to Yann for analyzing this.
Time to find my own mistakes...thanks for your help!
> Am 28.04.2016 um 02:40 schrieb Yann Ylavic :
>
> On Wed, Apr 27, 2016 at 7:28 AM, Stefan Eissing
> wrote:
>
On Thu, Apr 28, 2016 at 2:40 AM, Yann Ylavic wrote:
>>
>> What I saw was memory nullified, by assumedly, new apr_pcallocs, that should
>> not have been freed already. With more likelihood the more load and the less
>> logging, of course.
>
> So I'm rather thinking of a pool lifetime issue in h2
On Wed, Apr 27, 2016 at 7:28 AM, Stefan Eissing
wrote:
>
>
>> Am 26.04.2016 um 23:57 schrieb Yann Ylavic :
>>
>> On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing
>> wrote:
>>> Today I Learned the difference between writing
>>> DATA + META
>>> and
>>> DATA + META + FLUSH
>>> to the core output fi
Change was done in http://svn.apache.org/viewvc?view=revision&revision=327872
by brianp in 2005 with message:
"New version of ap_core_output_filter that does nonblocking writes
(backport from async-dev branch to 2.3 trunk)"
Since Brian put his name in CHANGES, it was probably him...
-Stefan
On 27 Apr 2016, at 2:49 PM, Stefan Eissing wrote:
> I had a look into 2.4.x this morning and while there are changes in filter
> brigade setaside code, the basic "cleanup" of empty and meta buckets before
> the setaside is there already.
>
> I think this has not bween noticed before as
> 1. E
> Am 27.04.2016 um 14:10 schrieb Jim Jagielski :
>
> Grrr... w/o looking too deeply into this, this seems very
> wrong. Is that a long-standing bug or something recently
> "optimized" away?
I had a look into 2.4.x this morning and while there are changes in filter
brigade setaside code, the bas
Grrr... w/o looking too deeply into this, this seems very
wrong. Is that a long-standing bug or something recently
"optimized" away?
> On Apr 26, 2016, at 10:49 AM, Stefan Eissing
> wrote:
>
> Today I Learned the difference between writing
> DATA + META
> and
> DATA + META + FLUSH
> to the
On 26 Apr 2016, at 4:49 PM, Stefan Eissing wrote:
> Today I Learned the difference between writing
> DATA + META
> and
> DATA + META + FLUSH
> to the core output filters. I am astonished that
> my code ever worked.
>
> Seriously, what is the reason for this kind of
> implementation? I would
On Wed, 27 Apr 2016, Stefan Eissing wrote:
The h2 use case is to pass a meta bucket that, when destroyed,
signals the end of life for data belonging to one stream. So all
buckets before that one should have been either destroyed or
setaside already.
One workaround could be a custom (data)
> Am 26.04.2016 um 23:57 schrieb Yann Ylavic :
>
> On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing
> wrote:
>> Today I Learned the difference between writing
>> DATA + META
>> and
>> DATA + META + FLUSH
>> to the core output filters. I am astonished that
>> my code ever worked.
>>
>> Serious
On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing
wrote:
> Today I Learned the difference between writing
> DATA + META
> and
> DATA + META + FLUSH
> to the core output filters. I am astonished that
> my code ever worked.
>
> Seriously, what is the reason for this kind of
> implementation?
Do y
Today I Learned the difference between writing
DATA + META
and
DATA + META + FLUSH
to the core output filters. I am astonished that
my code ever worked.
Seriously, what is the reason for this kind of
implementation? I would like to pass META buckets
in non-blocking way and *not* lose the or
13 matches
Mail list logo