Offloading readers in INN + CNFS

Dan Merillat harik at
Mon Oct 25 17:07:53 UTC 1999

Kjetil Torgrim Homme writes:
> [Dan Merillat]
> >   Not really a "solution", since it invloves guessing when the
> >   article is not available.
> Yes.  It should be possible to get output from the expire processes on
> the spools which can be used to adjust the expire times on the reader
> daily.  Or you can just check a couple of times a year.  I'm not
> saying it is perfect, but if your spool is large, you can spare room
> for some leeway.  Remember ARTICLE will still work, so you can fetch
> old articles by References.

Yes, but I'm not interested in syncing daily, yearly or even hourly.
The idea is to have the readers in-sync continually, and only run a check
weekly.  My proposal was for both types of article actions be fed to the
reader: creation and deletion.  This eliminates all the guessing games.

> Well, like I said, this gets hairy quick when the spools expire
> articles at different times.  If you have only one spool, or all

No, since the spools communicate to the INN process when they expire
an article.   With CNFS, this is continual.  With the others it's bursts
as they expire articles.  But the communication method is continual.

Also, at this point on the reader boxes you only have to compact history
and overview occasionally, rather then do a full expire run, just drop any
old records and recalc.  Expiry times can be down in the minutes range.

> spools have identical configuration, you can add special case
> communication between spool and reader server.  This setup may well be
> so common it is worth doing.  (Matt Dillon is strictly opposed to
> adding it to Diablo, he seems to think it spoils the purity of the
> design.)

Well, it dosn't need to be a special case.  Indeed, the expiration can 
happen with full inn communication, so even daily-type-expires (tradspool,
for instance) can use the same method-pushed communication.


More information about the inn-workers mailing list