Heiko Schlittermann wrote:
> Bill,
>
> W B Hacker<wbh@???> (Do 27 Jan 2011 16:16:11 CET):
>> Heiko Schlittermann wrote:
>>> W B Hacker<wbh@???> (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
