> > Mark Andrews <Mark.Andrews@dms.CSIRO.AU> wrote: > : Dieter Dworkin Muller wrote: > : > Some more investigation shows that this appears to be a problem with > : > the caching of active files. The active file for the remote server > : > gets updated immediately, as nntpcache.servers instructs: > : > > : > * information-retrieval.village.org 119 0.0.0.0 0 > 1h > : > > : > However, the active file that gets returned to the client never > : > changes: > : This is a timing issue. You have to read news between the > : minimum update period and the time specified in the servers > : file. > : > : I hacked my copy to change the order of the tests in list.c so > : that it merged if there was an out of date active in preference > : to transfering in a new active. At least with this scheme you > : get tranfer -> merge -> transfer -> merge instead of > : tranfer -> tranfer -> tranfer -> ... -> merger -> tranfer -> tranfer. > > Well, I've been poking around a bit since my last missive, and it > looks like this could be argued to be a bug (two different users read > news, wait an hour, read news again, with an active timeout of zero, > and the second read attempts report no new news). Chasing through > list.c, in UpdateCache(), if needsUpdate() returns -1 (cached copy of > active file from server is `fresh' and newer than our working active > file), then the working active file is updated with entries from the > cached copy of the server's active file. If, however, needsUpdate() > returns TRUE (cached server active file is `stale' and should be > updated) or FALSE (cached server active file is fresh, but not newer > than working active file, then we just use the working active file. > My claim is that in the case where the cached copy is to be updated, > we should go ahead and merge it with the working active file after the > update. > > To do this, in UpdateCache(), in the switch (needsUpdate(...)), add a > collect = TRUE inside the TRUE case. > > Now, this may be a problem that only shows up with a single remote > server, or with a lightly-loaded nntpcached. If, under heavier loads, > it does the right thing (in this case, not withholding new news for > excessive periods of time), then my change should probably be > conditionalized in some way. However, with this change, you can > control thrashing on the active file by setting the active file > timeout in the nntpcache.servers file, which is what it seems like > that parameter was intended for in the first place. > > To me, it looks like not setting collect in the needsUpdate()==TRUE > case is a simple oversight. That seems unlikely, so I'm pretty sure > I'm missing something here. What is it? > > Thanks. > > Dworkin > > This won't work when the system is bootstrapping itself into existance. Changing the fopen from "r" to "r+" should make this work. Mark -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 9325 3148 INTERNET: marka@syd.dms.csiro.au MOBIL: +61 41 942 9884 UUCP:....!uunet!syd.dms.csiro.au!marka
