> -----Original Message----- > From: Graham Leggett [mailto:minf...@sharp.fm] > Sent: Mittwoch, 10. November 2010 10:28 > To: dev@httpd.apache.org > Subject: Re: Proxy regressions > > On 10 Nov 2010, at 9:02 AM, Ruediger Pluem wrote: > > >> The fix in r1030855 is wrong: > ap_proxy_buckets_lifetime_transform is > >> not copying the data but only creates transient buckets > from the data > >> in the buckets in bb. If you then destroy bb before > passing pass_bb, > >> the data where the buckets in pass_bb point gets freed and > later gets > >> overwritten. > > > > Good catch. I reviewed the code again and then remembered > the idea why > > we use transient buckets: If everything goes well and the data is > > sent out > > by ap_pass_brigade no copying of the contents of the buckets is > > needed. > > Only if things are buffered somewhere down the chain, the > according > > filter > > needs to set the buckets aside (which causes copying). > > So I guess with the approach to release the backend connection > > immediately > > we will loose this advantage. That is regrettable. > > I guess an easy solution would be to use heap buckets instead of > > transient > > buckets. > > Have we not created a pool lifetime problem for ourselves here? > > In theory, any attempt to read from the backend connection should > create buckets allocated from the r->connection->bucket_alloc > allocator, which should be removed from the backend connection when > the backend connection is returned to the pool.
I guess we need a dedicated bucket_allocator at least in the beginning as we cannot guarantee that anyone in the create_connection hook uses the bucket_allocator to create an object that should persist until the connrec of the backend connection dies. Exchanging the allocator later each time we get the connection from the conn pool might create similar risks. But I admit that the later is only a gut feeling and I simply do not feel well with exchanging the allocator. I have no real hard facts why this cannot be done. > > Instead, it seems we create our own bucket_alloc from the backend > connection's pool, and then we only work because we're holding onto > the backend until we've stopped writing buckets - far longer than we > should be, and all along we've been working, but only by accident. In the light of these regressions I took a step back. My first thought on returning the backend connection to the connection pool asap was: This makes sense. Now after taking a step back I ask myself: Why is this benefitial? In the default configuration your connection pool to the backend can be as large as the number of threads you use per process in your MPM. So not returning it to the conn pool asap does not block any other thread from getting a connection to the backend from this conn pool. Only one exception comes to my mind where the asap returning makes sense: The maxium pool size has been configured to be lower than the number of threads. So without trying to offend anyone, can we see the use case for the asap returning again? Regards Rüdiger
