Stephen Gran wrote: > On Sun, Dec 07, 2008 at 09:54:42AM +0000, Graeme Fowler said: >> Hi Proskurin >> >> On Sun, 2008-12-07 at 12:38 +0300, Proskurin Kirill wrote: >>> Yes - what about mail query processing rewrite? >>> It is really slow and many company's have a Postfix to hold mail query >>> on it. >> I'm not sure I understand what you mean, here. Can you elaborate? > > The only way that sentence makes sense is s/query/queue/g > > I agree exim's queue processing could be faster, but it's not that bad. > My main annoyance on large installs is that occasionally it seems the > retry database loses it's marbles, and you end up with very wierd retry > behavior. I've never gotten enough of a test case together to produce a > useful bug report, unfortunately.
I have been thinking about this one over that last few months but haven't really run into a situation where I required a faster queue runner. My thoughts were along the lines of a separate exim process which would be a master queue runner, keeping the queue and retry in memory and have the exim processes that end in queue communicating via IPC/SHM/named pipes. Use an ordered queue keyed on next delivery time and only wake up when an attempt is due. The queue and retry could be written disk periodically, or simply rebuild from the /var/spool/exim files on start. I don't know if this would actually speed anything up though, or simply waste RAM and burn up cycles. -- The Exim Manual http://www.exim.org/docs.html http://docs.exim.org/current/ -- ## 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/
