> 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 >> To: dev@httpd.apache.org >> Subject: Fwd: Forwarded buckets' lifetime (was: [Bug 58503] segfault in >> apr_brigade_cleanup()...) >> >> [Meant for dev@...] >> >> Thoughts? >> >>> 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 >>> >>> Yes I agree, just proposed a quick patch to determine whether it came >> from >>> mod_proxy_wstunnel or some failure in the core deferred/pipelined write >>> logic... >>> >>> 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. When (sub-)request are used - and you may look at HTTP/2 processing as involving sub-requests, this model no longer holds and such functionality has a heavy price to pay. It needs to step very carefully to avoid the pitfalls of pool destroy cleanups on EOR. Given the complexity and the modules out there, I do not think it wise to change the behaviour of the existing apr_bucket_brigade in 2.4.x. I think it is better to think of an alternate bucket brigade design and maybe how that could live next to the old one in 2.4.x. Or skip 2.4.x entirely for this. //Stefan
