[Pan-users] Re: Pan 0.120 only queuing tasks

[Duncan]

Frederik Himpe <address@hidden> posted
address@hidden, 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