> On Jan 27, 2016, at 4:02 AM, Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com> wrote: > > > >> -----Original Message----- >> From: Yann Ylavic [mailto:ylavic....@gmail.com] >> Sent: Mittwoch, 27. Januar 2016 09:15 >> To: httpd-dev >> Subject: Re: svn commit: r1726787 - >> /httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c >> >> On Tue, Jan 26, 2016 at 1:57 PM, <rpl...@apache.org> wrote: >>> Author: rpluem >>> Date: Tue Jan 26 12:57:18 2016 >>> New Revision: 1726787 >>> >>> URL: http://svn.apache.org/viewvc?rev=1726787&view=rev >>> Log: >>> * Transform the buckets to the correct lifetime of the brigade, >> connection and filter stack that processes it. >> >> I'm not sure the buckets can be destroyed while in flight in >> mod_proxy_wstunnel, unlike with mod_proxy_http where the backend >> connection/request may be cleared before all data are out. >> >> ISTM that this can't happen here because we flush out on every write > > In theory this should be the case, but I think having brigade and buckets > allocated from > the same bucket allocator is a "better safe than sorry" approach that catches > possible > edge case now or in the future (think of Grahams ideas to have suspending > filters). > The issue with these possible edge cases is that it will be hard to find the > root cause, > because we likely segfault somewhere else. > And in fact it should cost us not much here as the buckets are likely memory > buckets already > and nothing is really done with the content if no one sets it aside. >
Makes sense to me... +1
