>> You start up N queue-runner daemons; one for each named queue -
>> as well as the traditional one which runs the un-named queue
>> and also handle inbound smtp.
>
> Could you create a router that exists solely to run a sleep command if a queue run is being performed?
>
> slow_queue:
> driver = accept
> condition = ${if queue_running}
> condition = ${run{/bin/sleep 30}{yes}{no}}
> no_verify # Don't execute during ACL verification
> unseen # Pass message to next router even though we've accepted
>
> Bit of a hack but combined with strict queue-runner limits seems like it could work to effective throttle. Haven't tested, maybe some pitfalls?
Uh... Sorry.. Haven't had my morning coffee (and it's 11.21 AM here in
Sweden now!), but, I don't understand what this would accomplish... I
like the emails being generated from my database system to be queued
for delivery by Exim, I don't want my database-system to wait for each
message before it's put in the queue. Depening on what function where
talking about there's usually 100 to 50k unique messages generated for
the users. I rather have my database perform other jobs then spooling
to Exim for a hour or two. ;)... Or... Have I missunderstood this
completely? Do the routers get executed AGAIN when Exim handles the
queue?? I thought they were just executed on receiving a message..
I certainly see why this is a good ide for OTHER users performing SMTP
to my server though. Nice throttling idea!