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 mailing list