On Thu, Sep 15, 2005 at 09:49:38AM +0100, Philip Hazel wrote: > > As a matter of fact, people use G because they want the exponential > > backoff and nobody cares about the actual interval. > > Do you have evidence for that assertion? I am almost willing to bet that > if this change were made, at the very least somebody would be posting > questions to the list as to why, after waiting an hour between tries, > Exim then only waited 10 minutes before the next try.
Evidence is a hard word. When I asked about making this patch initially, all I heard is: You don't need it, queue runs are not synchronised and there is nothing a random interval could do any better than the randomness introduced by life. Go fix your system. So obviously nobody answering ever checked the intervals really. Well, I didn't during the last years, either. I just noticed that sometimes things turn out odd and thought: That's randomness. It's mean somtimes. Surprisingly, in my situation, queue runs turned out to be self-synchronising and under load that was always bad, but not always bad enough to cause real trouble. The answer to the question above is of course: If a number of systems wants to deliver mail to a previously down host, and their master daemons start at the same time (cluster or due to reloading at midnight from cron), and their retry/queue run configuration is the same (cluster or a common default configuration), then they may all hit the previously down host at the same time, overloading it, and not delivering much mail, not retrying until the next battle. Are you willing to bet that somebody would still like to get the old behaviour back? Thanks goodness Exim did not yet take over the world, neither did a specific OS distribution or usage of NTP, or this might be a much larger problem. Btw: BIND does something similar for zone reloads, for pretty much the same reason, and you can not change it. So does Ethernet. I really would like to change 'G' and have all systems acting different. Still no evidence, I am afraid, but at least good reasons for the change. :) Michael -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
