earle@jplopto.uucp (Greg Earle (40876)) (06/30/87)
In article <4161@jade.BERKELEY.EDU> (Brent Chapman) writes: >In article <4027@elroy.Jpl.Nasa.Gov> (Greg Earle) writes: >>I no longer have access to either the `rrn' nor `nntp' source, so I'll >>throw this out: >>Imagine a Worst Case scenario: >> Leave for vacation for 2 weeks. Return, and fire up rrn (this may >>be an `rn' problem as well, I dunno). Get to soc.singles (best example). >>Discover `1234 unread articles in soc.singles' (or similar huge number). > >This doesn't address all the issues Greg mentioned in his posting, but it >does help after long absences. Auugh! Even doing the quick cancel didn't keep the virus from spreading ... To anyone that saw my original article (complaining about seeing lots of `Skipping (xxx unreadable.)' messages in high volume groups when unread for a while): The *symptoms* I described were and still are true. The *mechanism* that I proposed for *why* the symptoms occur was *WRONG*. Unfortunately, this makes the resulting behavior even more bizarre! What I said, in essence, is that it appeared that if one had read up through article (say) 1000 in talk.highvolume, and then not read anything for a while, then one would find that upon returning to the newsgroup, if the current lowest-numbered article was, say, now 1250 (let's say the latest article is now 1500), due to expirations in the meantime, that `rrn' would cycle from 1001 (next assumed unread article according to your .newsrc) to 1250 (next real-live readable article) giving the abovementioned `Skipping (1xxx unreadable.)' cycle for those 250 articles in the gap between your .newsrc and the active file. Even on a 1200 baud phone line, this eats up much time and $$$. Well, I should have given `rrn' more credit for that, and waited to check it out before posting (Heck, I cancelled it 5 minutes later; I tried). Now, the crazy thing is - `rrn' *does* know enough to mark all the gap between .newsrc and the active file as read; yet this problem STILL occurs; and it is happening with article numbers that *ostensibly should exist* according to the active file. In other words, given the same example as above (talk.highvolume: 1-1000 in your .newsrc; talk.highvolume 01500 01250 in the active file), presumably the active file, as cached in /tmp at the start of your `rrn' session, is accurate. Yet `rrn', when reaching this group, will *correctly* start off trying to read (presumably) existing articles at #1250, as it should; yet I have *still* seen literally dozens of article numbers *in the valid range* stream by as `Skipping ... unreadable' before hitting `readable' articles. This is exacerbated by not being able to directly access the spool directories on the news server machine, so I cannot directly test whether the articles do indeed exist or not (and thus localize the problem and reduce net bandwidth (-: ). Thus, things become even stranger - the presumably-correct-and-up-to-date active file says one thing, but when the articles are accessed `rrn' says another. Without source *and* access to the spool directories it is difficult to assign the problem/blame. I throw this out to see if anyone else has encountered this problem, and knows where the fault lies. It is extremely frustrating to not be able to tell `rrn' to shut up about long series of articles it cannot access, that it should be spending its CPU cycles finding a readable one, not racking up my phone bills droning on and on about the ones it couldn't read ... I hope this has made things a little clearer. Greg Earle earle@{jplpub1,jplopto}.JPL.NASA.GOV (Now ex-)JPL jpl{pub1,opto}!earle@jpl-elroy.ARPA jpl(pub1,opto}!earle@elroy.JPL.NASA.GOV seismo!cit-vax!elroy!jpl{opto,pub1}!earle