2.3exp: expire and tradspool
Richard Michael Todd
rmtodd at mailhost.ecn.ou.edu
Sat Aug 21 22:24:16 UTC 1999
In message <19990821161431Y.kondou at inn.do.mms.mt.nec.co.jp>you write:
>In article <m11I3kt-000FaBC at independence.ecn.ou.edu>,
> Richard Michael Todd <rmtodd at mailhost.ecn.ou.edu> wrote;
>
>} end up in the same directory tree, so the notion of 'storage class' doesn't
>} really make sense here.
>
>I think we can get the class for articles with a routine
>like SMstore() does. This can be used at tradspool_next().
>I'm going to modify the code after overview code is mostly
>stable and NEWNEWS is available again.
>
>} a) whether this would be an acceptable limitation or
>} b) whether they can think of a scheme for per-group expire that would be
>} decently efficient, and *doesn't* have that limitation.
>
>I'm thinking of another approach:
>
>- expireover reads expire.ctl, determines expiration time
> with Xref, and write token to a file if it should be
> expired
>- sort that file and do SMcancel with those tokens
>- expire just checks with SMretrieve(RETR_STAT)
Um. But doesn't that mean that expire won't work unless you have overview
enabled? That doesn't sound like a good idea. That and you need to have
expireover run every time expire runs.
>btw, expireover takes much longer time if most of articles
>are spooled into timecaf. I know why it does;
>SMretrieve(RETR_STAT) needs to open caf file even if it
>just checks the existense. Any resolution?
Not any easy one I know of. Timehash is probably the same way. We could hack
timehash and timecaf to keep a database of the currently active tokens
in spool, but that would slow down writes and add one more thing to get out
of sync.
One thing that might be useful is changing how expireover works to make it
back to taking the list of articles that expire expired, and putting them in
a hash table. That way expireover doesn't have to SMretrieve(RETR_STAT)
each article to see what's gone, it can just look at the list from expire.
Of course, this wouldn't catch articles that had been canceled/NoCem'ed etc,
so you would still need the 'full' expireover that stated every article, but
that one you could have run less often.
More information about the inn-workers
mailing list