Heiko Schlittermann wrote: > Bill, > > W B Hacker<[email protected]> (Do 27 Jan 2011 16:16:11 CET): >> Heiko Schlittermann wrote: >>> W B Hacker<[email protected]> (Do 27 Jan 2011 00:06:53 CET): >>>> Sergei Gerasenko wrote: >>> … >>>>> * * F,2h,15m; G,16h,1h,1.5; F,4d,6h >>>>> Thanks! >>>> >>>> The retry (alone) fires a queue-runner every 15 minutes for the first 2 >>>> hours, >>>> etc .. >>> >>> Until now I thought, that queue runners are started according the "-q…" >>> option. (Or additionally triggered by external means (cron, >>> some user, …) The 15m above just means, that during the first 2 hours the >>> *minimum* distance between to delivery attempts has to be 15 minutes. >>> >>> The spec reads: >>> >>> | Retry times are hints rather than promises. Exim does not make any >>> attempt to >>> | run deliveries exactly at the computed times. Instead, a queue >>> runner process >>> | starts delivery processes for delayed messages periodically, and >>> these attempt >>> | new deliveries only for those addresses that have passed their next >>> retry time. >>> >>> Please correct me, if I'm wrong. >>> >>> >> >> Hopefully, docs and 'We' are all saying the same thing. >> >> To clarify what *I* said - >> 'whatever ELSE may fire a queue runner, the retry rule is more concerned with >> WHICH frozen messages are eligible for retry at a point in time than with >> invocation of the queue runner itself. > > Ok, I understood your "retry fires a queue runner…" in a different way. > > And … we need to be more precise: *frozen* messages are not subject to retry > rules at all. (except probably after > ignore_bounce_errors_after/timeout_frozen_after has passed) > > >> The implication is that a pass is made over the queue at NO LESS >> THAN<whatever >> is in the retry rule>.. > > The queue runners are started regardless the retry rules (by the > master process via "-qXXm", cron, users…). They just skip the *messages* not > sitting > for long enough in the queue. > >> AFAIK, setting to queue_only is a minority use of Exim, so ..ordinarily, >> every >> transit invokes a queue runner, which hopefully succeeds on the first go more >> often than not, thereby leaing nothing in the queue when all is well. > > Here *I*'m not sure. A delivery attempt is made for every incoming > message, independend on the retry rules. But I'm not sure, if this > specific delivery process than starts walking the queue too. > >> Are we clarifying or confusing? > > Not sure ☺ > >
Some of both, I suspect. AFAIK, ANY 'vanilla' queue runner fired - regardless of what fired it - will then follow the same hints, obey the same retry/frozen flags and walk the whole queue. I now say 'vanilla' 'coz, of course one can fire a specific other 'flavor' of queue runner (or - perhaps more accurately a functional equivalent) to go and look only at frozen, or only at specific messages, etc. But back to the orignal theme: As retry rules essentially catch a ride on queue-runners triggered 'otherwise', and do NOT trigger their own, it is possible, though I submit probably quite rare, that retry can be overlooked for hours - even days - under edge-case circumstances. I wonder if that should be changed such that a queue runner IS run within the retry parameters if it has not otherwise been invoked during the appropriate time span. Thoughts? Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
