Speeding tradspool expiry
rra at stanford.edu
Thu Jan 4 05:19:03 UTC 2001
Katsuhiro Kondou <kondou at nec.co.jp> writes:
> Russ Allbery <rra at stanford.edu> wrote;
> } I want to use a large tradspool spool for my new reader server, so I'm
> } trying to tackle the slow expiration speed problem that was introduced
> } when we went to the storage API.
> I think this should be fixed also for many other news admins.
Okay, I went with my original idea, which is really a hack but it was fast
and I need to get the new server up this week. I'll start committing the
pieces of it tonight, probably, now that I've finally got it tested and
working. Ran into a few other interesting bits to fix too while I was at
> } Does this sound okay to people, and does anyone have any other ideas?
> Storage api brings us not only general method to access articles
> but also thick wall when accessing thru tradspool.
Yeah. :/ It's really annoying. It's made me wonder if we should
consider trying to store the crossposting information in the storage
mechanisms somehow. But that would require a format change of all of
them, plus probably a good way of assigning numbers to groups so that the
information is somewhat compact (in other words, tradspool.map for all of
INN), and that's a huge project and not something I really want to tackle
after a few other things have been taken care of.
The whole expire system really needs to be reworked, though; I keep
getting confused when I try to work on it. I think merging expire and
expireover may be a good idea in the long run, but I haven't really
thought about it much yet. When I get a chance, I'll try to think through
the architecture and see if I can come up with a structure that would make
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers