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
