Re: TIL

2016-04-28 Thread Ruediger Pluem
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 >>>

Re: TIL

2016-04-28 Thread Stefan Eissing
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,

Re: TIL

2016-04-27 Thread Yann Ylavic
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

Re: TIL

2016-04-27 Thread Yann Ylavic
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

Re: TIL

2016-04-27 Thread Stefan Eissing
Change was done in http://svn.apache.org/viewvc?view=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 > Am

Re: TIL

2016-04-27 Thread Graham Leggett
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

Re: TIL

2016-04-27 Thread Stefan Eissing
> 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

Re: TIL

2016-04-27 Thread 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? > On Apr 26, 2016, at 10:49 AM, Stefan Eissing > wrote: > > Today I Learned the difference between writing > DATA + META > and

Re: TIL

2016-04-27 Thread Graham Leggett
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

Re: TIL

2016-04-27 Thread Niklas Edmundsson
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)

Re: TIL

2016-04-26 Thread Stefan Eissing
> 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

Re: TIL

2016-04-26 Thread 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. > > Seriously, what is the reason for this

TIL

2016-04-26 Thread Stefan Eissing
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