Frederik Himpe <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 28 Apr 2007 21:14:05 +0000:
> I seem to have a similar problem. I'm using Pan 0.128, and I see the > problem especially when using news.gmane.org in the evening (CEST) or in > the week-end, probably when that server is higly loaded. > > I click on a newsgroup, and in the taskbar it first says "Tasks: 1/1", > and after some time, it becomes "Tasks: 0/1". At this point no new > headers in the group appear. When I click on the "Task" message in the > status bar, I see the status is "Queued". If I delete the task, suddenly > all new messages appear, and everything is working well. > > I guess this should be fairly easy to reproduce for everyone with > news.gmane.org OK, I recognize the problem now, but IIRC I've never seen it on gmane (which I do use), but mainly on my ISP's servers, but also on my paid server once in awhile. Fortunately it doesn't happen too often here as it is CERTAINLY frustrating when it does! AFAIK from the last time this came up and from discussion by non-pan users at my ISP (Cox, now outsourcing from highwinds-media, which / sucks!), it's not just a pan problem, but has to do with "lossy" connections. TCP (which underlies NNTP) simply doesn't work very well with lost packets because it either interprets them as congestion and slows down in the one case, or causes lost ACKs and thus "zombie connection" syndrome. The latter is generally the problem in the case at hand. If it's what I think it is, pan has sent ACKs for packets it has received, saying it received them, send more (or maybe retransmit requests if it didn't receive them), only the server never got the ACKs, and having filled the allowed RcvWin without getting the ACKs saying those are processed and allowing it to continue, it can't send more. So both ends are waiting on the other to act, as the connection handshake and control element got broken. Hitting stop allows pan to process the partial data it has. Unfortunately, while pan will start the connection terminate process, sometimes that gets hung as well. Sometimes a pan restart is necessary, and if the thing is /really/ screwed up, the kernel may not be able to finish closing some of those connections until it times them out. (In the worst-case, I believe they can hang around for 24 hours. =8^( ) One may then need to reboot to get them gone, if one isn't patient enough to wait for it to happen on its own. One of the problems with highwinds-media is their software. Highwinds software, while it runs on high-end equipment and when it is perfectly tuned for its load and hardware it pretty much blows anything else away (highwinds <g>), it's notorious for being /extremely/ finicky about its tuning and it has been the experience of many unfortunate users of servers running it over the years that it seldom performs at peak rating for more than a few months, when some variable or another gets out of balance and it must be painstakingly tuned again -- only it's not just that one tunable that must be adjusted but pretty much the entire thing, the result of all this being it often spends more time limping along than it does performing at speed. That's the one problem. Complicating it is an operational policy with a single authentication server managing two server farms, one of which it's remote to. The problem being that on bad connections, the front-ends actually serving the content often send TCP resets or otherwise break-off the connection, but the news doesn't make it to the authentication server, so it won't allow any more connections to replace the ones gone bad and terminated. Gmane is running INN, from the login banner. (I just telnetted in to see.) Fortunately, while it doesn't scale up as far (in theory) as highwinds does, in this case that's a good thing, since a broken config is far easier to fix and far less likely to remain in place, hobbling along for months at a time. Thus, things aren't as bad as they might be. However, apparently at least one hop of the connection between you and gmane is either congested or otherwise unreliable enough to cause dropped packets -- enough to cause the connection headaches you seem to be seeing. All that said, there's a small chance that pan's hanging on the finished data, and simply not getting unstuck until you hit stop. I doubt it, however, as I expect I'd be seeing gmane problems too, and I'm not, while others with other readers are seeing problems of a similar nature here on Cox. Fortunately, my connection is more solid than many seem to be. I've noticed that in several areas, and this is no exception. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
