On Tue, Nov 30, 2010 at 11:31:45AM +0000, Graham Keeling wrote: > On Tue, Nov 30, 2010 at 09:46:47PM +1300, Amos Jeffries wrote: > > On 30/11/10 21:23, Oguz Yilmaz wrote: > >> On Tue, Nov 30, 2010 at 10:05 AM, Amos Jeffries<squid3@xxxxxxxxxxxxx> wrote: > >>> On 30/11/10 04:04, Oguz Yilmaz wrote: > >>>> > >>>> Graham, > >>>> > >>>> This is the best explanation I have seen about ongoing upload problem > >>>> in proxy chains where squid is one part of the chain. > >>>> > >>>> On our systems, we use Squid 3.0.STABLE25. Before squid a > >>>> dansguardian(DG) proxy exist to filter. Results of my tests: > >>>> > >>>> 1- > >>>> DG+Squid 2.6.STABLE12: No problem of uploading > >>>> DG+Squid 3.0.STABLE25: Problematic > >>>> DG+Squid 3.1.8: Problematic > >>>> DG+Squid 3.2.0.2: Problematic > >>>> > >>>> 2- We have mostly prÄblems with the sites with web based upload status > >>>> viewers. Like rapidshare, youtube etc... > >>>> > >>>> 3- If Squid is the only proxy, no problem of uploading. > >>>> > >>>> 4- ead_ahead_gap 16 KB does not resolv the problem > >>>> > >>>> > >>>> Dear Developers, > >>>> > >>>> Can you propose some other workarounds for us to test? The problem is > >>>> encountered with most active sites of the net, unfortunately. > >>> > >>> This sounds like the same problem as > >>> http://bugs.squid-cache.org/show_bug.cgi?id=3017 > >> > > > > Sorry, crossing bug reports in my head. > > > > This one is closer to the suck-everything behaviour you have seen: > > http://bugs.squid-cache.org/show_bug.cgi?id=2910 > > > > both have an outside chance of working. > > I have tried both suggestions, and neither of them make a difference > (changes to BodyPipe.h and client_side_request.cc). > > I am keen to try any further suggestions, or provide you with debug output, > or whatever you like. > > This problem is extremely easy for me to reproduce. > It happens without any authentication, and with squid as the only proxy between > my browser and the website. > > Shall I enter a proper bug report? To demonstrate the problem happening, I set on 'debug_options 33,2' and re-ran my test. This shows that ConnStateData::makeSpaceAvailable() in client_side.cc will eat memory forever. I can turn on more debug if needed, but others should be able to easily reproduce this. 2010/11/30 11:57:17.482| growing request buffer: notYetUsed=4095 size=8192 2010/11/30 11:57:17.483| growing request buffer: notYetUsed=8191 size=16384 2010/11/30 11:57:17.483| growing request buffer: notYetUsed=16383 size=32768 2010/11/30 11:57:17.484| growing request buffer: notYetUsed=32767 size=65536 2010/11/30 11:57:17.486| growing request buffer: notYetUsed=65535 size=131072 2010/11/30 11:57:17.488| growing request buffer: notYetUsed=131071 size=262144 2010/11/30 11:57:17.506| growing request buffer: notYetUsed=262143 size=524288 2010/11/30 11:57:17.533| growing request buffer: notYetUsed=524287 size=1048576 2010/11/30 11:57:17.586| growing request buffer: notYetUsed=1048575 size=2097152 2010/11/30 11:57:17.692| growing request buffer: notYetUsed=2097151 size=4194304 2010/11/30 11:57:17.884| growing request buffer: notYetUsed=4194303 size=8388608 2010/11/30 11:57:18.308| growing request buffer: notYetUsed=8388607 size=16777216 2010/11/30 11:57:19.136| growing request buffer: notYetUsed=16777215 size=33554432 2010/11/30 11:57:20.792| growing request buffer: notYetUsed=33554431 size=67108864 2010/11/30 11:57:23.957| growing request buffer: notYetUsed=67108863 size=134217728 2010/11/30 11:57:31.176| growing request buffer: notYetUsed=134217727 size=268435456 2010/11/30 11:57:58.433| growing request buffer: notYetUsed=268435455 size=536870912 ...
