On Tue, Oct 20, 2015 at 10:42 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 20.10.2015 um 09:44 schrieb Plüm, Rüdiger, Vodafone Group >> <ruediger.pl...@vodafone.com>: >> >>> -----Original Message----- >>> From: Yann Ylavic [mailto:ylavic....@gmail.com] >>> Sent: Montag, 19. Oktober 2015 22:30 >>>> >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58503 >>>> >>>> --- Comment #8 from Yann Ylavic <ylavic....@gmail.com> --- >>>> (In reply to Ruediger Pluem from comment #7) >>>>> Actually I think mod_proxy_wstunnel falls into the same pitfall >>>>> mod_proxy_http was in and it needs to do the same / something similar >>> then >>>>> mod_proxy_http.c with >>>>> >>>>> proxy_buckets_lifetime_transform >>>> >>>> >>>> We need to either use lifetime_transform like in proxy_http, or I was >>>> thinking >>>> of modifying all the input filters that create their buckets on f->r/c's >>>> pool/bucket_alloc so that they now use their given bb->p and bb- >>>> bucket_alloc. >> >> I don't think that this is a good idea, because bucket brigades sometimes >> have a longer lifetime >> then the buckets that are created right now with f->r/c'spool/bucket_alloc. >> They get created and are kept >> and only get cleared to avoid creating them over and over again. So this >> step can open up a big >> can of worms. Furthermore it is an API change, because currently the caller >> expects the buckets >> are created with f->r/c'spool/bucket_alloc und you cannot change that >> expectation for 3rd party modules. >> >> So if at all a change for trunk only that requires a very deep review of all >> brigade usages. > > As I learned, bucket brigades are very optimized for the common HTTP/1 case: > appearing during one > request and going away together with the request - preferably with only one > thread involved.
What I proposed is precisely to let the caller of ap_get_brigade() decide the lifetime of the buckets it gets, by the involved input filters playing the game. But I agree we would still need a "safe guard" like bucket_lifetime_transform() which would do the right thing for (third-party) buckets that do not match, whereas in the common case we would avoid any copy. I suspect this could also help the h2 case by having spare/recycled brigades which could be shared/exchanged with the single writer on the client connection. I'm not sure this would break anything in 2.4.x, but since this is quite theorical for now, let me try a first implementation which will help me think more about the implications. Regards, Yann.
