ctlinnd cancel ... ?
Richard Michael Todd
rmtodd at mailhost.ecn.ou.edu
Sat Sep 11 20:32:53 UTC 1999
In message <19990911232742L.kondou at inn.do.mms.mt.nec.co.jp>you write:
>I see this with timecaf, and I suspect you're also
>running timecaf. This happens, until another cancel
>on the different file is done. I think this is due
>to gain good performance when fastrm is invoked. Am
>I right, Richard? If so, SMsetup(SM_IMMEDIATECANCEL)
Ah, yes. You're right, that caching code is to speed up fastrm; the side
effect is that cancels done by innd don't take effect immediately, but only
when a cancel occurs in a different file.
>which is not impletented yet would be solve this.
Or (my preference) implement a general SMflushcacheddata() call that
gets called from innd whenever it does its flushes of the
active/history file in ICDwrite(). That way, if you're getting a lot
of cancels for articles that came in in a small period of time, you'd
still get the benefit of the cache, but if you wanted a ctlinnd cancel
to take effect immediately, you could follow it with a ctlinnd
throttle/ctlinnd go to force innd to flush everything. Or you could
decide you don't *care* if it gets flushed immediately, and rest
assured that it *would* take effect within the next 'nnn' seconds (300
by default, DEFAULT_TIMEOUT).
This would also generalize to any other sort of data caching we might
choose to implement in the other storage managers later.
More information about the inn-workers