> I've used tin (currently v1.4) as my normal news reader for many years now
> without a problem. However, it seems to be having a problem re-reading the
> active file from the new nntpcache server I set up.
I should maybe mention here that last time I spoke to Proff, tin/FreeBSD
were his preferred development environment, so that combination is the
primary test combination, and should be the most solid. Course it's been
a while since I last spoke to Proff on this matter, he may have changed
his preferences since. Don't let the author attributions mislead you.
Even though it lists me as an author, I don't think there's a single
line of my code left in there, but the basic algorithm and the (ugly)
prototype was written by me which is why my name still appears there.
Plus I'm still around to interpret RFC's and related documentation in
a lawyer-like fashion and throw in my $0.02 on occasions ;-).
> In tin, if you press 'Y' or after it times out, it'll re-read the active
> file to see if there's any new articles. However, unless I restart the
> nntpcache daemon (which takes about 20 minutes) or enter a newsgroup and
> immediately exit, it doesn't think that there are any new articles to be
> read. I've tried tin v1.3 and v1.4 and also tried removing the .tin
> directory in case it was caching anything. Quitting and restarting tin
> doesn't seem to help either.
It may help sometimes, since nntpcache checks the expiry times of things
like the active file, so disconnecting and reconnecting (ie. stopping and
restarting tin) only when a client connects, or a signal is sent to it
to tell it to do so. Even if it finds one of these files has expired,
it will still hand you the old data, then fork off and rebuild the
necessary files. We once made the client wait until the rebuild process
is complete before handing out the data, but when you've got multiple
servers in your config merging them into what appears to be a single
virtual server, with some links being congested or some servers being
slow, we found rebuild times could take hours some times, so Proff
thought it better to hand out the expired data to the client, then
trigger a rebuild.
> Netscape Collabra seems to re-check for new articles fine (I found a rare
> problem with that as well, but it probably isn't related). BTW, all programs
> are running on Sun Ultra's running Solaris 2.6.
>
> Any ideas as to why this is happening would be appreciated. Thank you very
> much!
As already stated on the list, Collabra doesn't use the active file
as much as tin does. It uses the response to the GROUP command to find
articles available instead of the active file. Therefore you are getting
current data from the server instead of a cached active file.
The advantage to Collabra's approach is obvious, since it gets more
current data. The disadvantage to that approach is it is more
sensitive to longish RTT times, which can get to be a real pain
if the link from nntpcache to the server gets to be congested
enough to push RTT times up.
The only workaround that I can think of for adding to nntpcache
is to check the article numbers on each GROUP command against
it's cached active file, and if it turns out that the relevant
line of the cached active file is out of date send
"list active <group-name>" to the server just to update the
high and low articles for that group. But that would greatly
increase the load on the servers.
Another approach may be to use the response from the GROUP
command to update relevant parts of cached of files. Off the
top of my head it seems the response to the GROUP command
is adequate for updating all the relevant cached files, but
instinct tells me that somewhere in one of the cached files
is data that can't be updated solely on the response to
the GROUP command, and it's far more important that all
the locally cached active, active.times, etc. are consistent.
Experimentation seems to be called for here.
> Jeffrey Veiss (jsv@bms.com) PO Box 5400
> Network Engineer Princeton, NJ 08543-5400
> Corporate Telecommunications (609) 818-3308
> Bristol-Myers Squibb (609) 818-7814 (fax)
I should probably take this opportunity to point out that setting
timeouts for various files like active, active.times, etc. Is
something that we could get into a heated flame war about. Most of
the problems I see reported both on this list and in email to
me are usually a case of a poor configuration. A good configuration
depends on bandwidth to the server(s), load on the server(s),
RTT to the server(s), frequency of client connects, and probably
a few other things I can't think of off the top of my head.
Rather than starting a flame war, I'd prefer to develop an
equation to be used as a _guide_ to setting up the configs,
and perhaps a friendlier interface for admins to set up
the config files, since it seems that much of the critism
I see popping up in my mailbox I feel like responding to
with "go RTFM", but I suspect it's more a case of news admins
not understanding what some of the numbers mean and just
leaving them at default settings. In the days when we had
our suburbia.net config as an _example_ config, news.suburbia.net
got utterly pelted with traffic from people not changing
the server config despite many comments in the config files
stating that it was a parameter that had to be changed.
I suspect it's more a case of people not _understanding_
the docs rather than not reading them at all. We here
are intimately familiar with the code, whereas others
obviously aren't. A non-coding problem which we tend
to put in the "our supply of round tuits is too low at
the moment" bin^H^H^H folder, which so many programmers
tend to do. I hereby make a statement that I _will_ look
at this problem in the near future ("near" meaning within
a few weeks, just so I can't fall back on the excuse of
saying that I mean "near" on geological timescales). I
can't guarantee a time limit on actually "fixing" the
problem with much certainty at all, since until I look
at the problem I don't even know if it's really a
problem at all. I'm just guessing it's the problem
at the moment. It may turn out that the "problem" is
really a manifestation of "features" instead. All
I can promise is to look at the "problem" and promise
to report my analysis on this list. A "fix" could
be months away after that.
--
Luke Bowker, puke@tinkertrain.suburbia.net (preferred), puke@deakin.edu.au
lpb@ne.com.au
Suburbia Public Access Network Site Sysadmin
"To be so free, it took so long.
It's not journey's end, it's just begun." - Iron Maiden
