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