The problem still seems to exist in that version. More specifically though, I wasn't able to reproduce the bug on my debian box, which happens to run the apt-cacher-ng proxy. I ran 'apt-get update' a few times and all seemed okay. However on my ubuntu box, I still get the error particularly for ppa.launchpad.net repos, and the problem seemed more pronounced when I was running 'apt-get update' on both boxes at the same time. These were the repos, if you'd like to give it a try yourself:
> W: Failed to fetch > http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/vivid/main/binary-amd64/Packages > > 502 Connection closed > > W: Failed to fetch > http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/vivid/main/binary-i386/Packages > > 502 Connection closed > > W: Failed to fetch > http://ppa.launchpad.net/webupd8team/tor-browser/ubuntu/dists/vivid/main/binary-amd64/Packages > > 502 Connection closed > > W: Failed to fetch > http://ppa.launchpad.net/webupd8team/tor-browser/ubuntu/dists/vivid/main/binary-i386/Packages > > 502 Connection closed Anyway, I've had a look at the code again, and I think I understand now why the original code which I reverted back to worked for me. No host would ever be blacklisted since nLostConTolerance always got reset in the middle of the big while loop. So I understand why your changes were necessary. I have retested another build with MAX_RETRY set to 10, and it looks a little more promising now. Perhaps this would need to be a configurable variable. Thanks for all your hard work! -Carlos On 17/07/15 02:37, Eduard Bloch wrote: > Control: tags 792541 +pending > > Hallo, > * Carlos Maddela [Thu, Jul 16 2015, 09:06:00AM]: >> Package: apt-cacher-ng >> Version: 0.8.4-1 >> Severity: important >> Tags: patch >> Control: found -1 apt-cacher-ng/0.8.2-1 >> >> Hello, >> >> Often, when performing 'apt-get update' with apt-cacher-ng, it would >> fail with lots of '502 Connection closed' errors, as shown in the attached >> apt-cacher.err snippet. I don't know why no one else has reported this yet, >> but maybe it has something to do with slower internet connections. >> >> I thought the bug may have been related to Bug #787289, so I tried different >> PipelineDepth values, but it didn't change anything. >> >> I did a bit of debugging and found that the problem first crops up after >> this commit: >> >> https://anonscm.debian.org/cgit/apt-cacher-ng/apt-cacher-ng.git/commit/?h=debian/sid&id=1716a7a94c0e6bfc0635f2aef6e281c10a30a96c >> >> Without understanding the code entirely, I tried reverting some of the >> changes that I thought were suspect, and it seemed to do the trick. >> I have attached this patch. Hopefully, it doesn't cause problems for others. > Thanks. That's interesting, I found a similar (probably the same) issue > a couple of weeks ago and traced this back to the broken (re)setting of > this nLostConTolerance variable. It seems like the bug has been existing > for a while but the effects were covered up by another code path or just > triggered a reconnection which covered all tracks. When I added TLS > handling, it started shining through. > > Could you please test a build from the latest master tree? I guess > https://anonscm.debian.org/cgit/apt-cacher-ng/apt-cacher-ng.git/commit/?h=debian/sid&id=f3e8e60f88db4c9aeb6e33acd60da87dca426587 > should have fixed your problem (just pushed, wasn't there this morning). > > This reminds me on getting out 0.8.5 ASAP :-( ... > > Regards, > Eduard. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
