> -----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. > (btw that could be optimized to flush outside the loop). Could be. The question is, whether this is ok from the websockets responsiveness point of view. OTOH we do an non blocking read. So this should be fine. > So provided we clear the working brigade before leaving, isn't that > enough already? As said above, I feel a little bit uneasy about stuff that could happen in the filter chain having these buckets still alive in different brigades. Regards Rüdiger
