On 06/08/2013 08:17 PM, Wietse Venema wrote:
Jeroen Geilman:
On 06/04/2013 02:20 PM, Erwan David wrote:
On Tue, Jun 04, 2013 at 01:44:46PM CEST, Tom Hendrikx <t...@whyscream.net> said:
On 06/04/2013 01:22 PM, Antonio Guti?rrez Mayoral wrote:
Hi Wietse,
Yes, its a solution, but these emails should be delivered in
bussines-time :-(
(it doesnt matter if it takes 2 hours... but in bussiness time...)
thank you so much!
You could run a script as a cronjob that queues x messages when the
active queue contains (100 minus x) messages (where 100 is an arbitrary
number). This means that all mails on HOLD trickle out as quick as
possible, while not overloading the active queue...
It means when the queue has 100 messages, you stop sending anything ?
You could check the headers for identifying features (maybe the list ID,
or a subject part, or...whatever works), and instantly DEFER them.
This will put all messages in the deferred queue, guaranteeing they
won't choke incoming: if the deferred queue is not empty, one message
will be taken from incoming and deferred, in turn.
Currently the queue manager can group recipients into jobs when
they share the same queue file, and uses that to prevent a limited
number of many-recipient messages from blocking later email
with fewer recipients.
The fix would be to group recipients into jobs based on the sender
attribute (or size, or whatever) and apply similar logic to prevent
a limited messages from one sender from blocking later email from
other senders (or or to prevent large messages from blocking later
messages that are smaller in size).
However if one sender manages to saturate the queue then it will
take time before other email gets a chance to be scheduled.
Wietse
I thought the queue manager took one message each from deferred and
incoming if deferred is not empty, keyed on the destination next-hop
(resulting in one "virtual queue" per destination); this allows one to
manipulate the way messages are queued by limiting the number of
recipients per message.
If he can just use a transport with a single-recipient limit to send his
newsletter to, that would take care of the blockage, wouldn't it ?
The queue manager doesn't combine multiple queue messages AFAIK, so even
if there are hundreds of large single-recipient messages with the same
next-hop in the deferred queue, it would only take one message (plus its
one recipient) every time, and a single message from incoming after that.
--
J.
