On 9/12/2012 1:27 PM, DN Singh wrote:
> 
> On Sep 11, 2012 8:43 PM, "Wietse Venema" <wie...@porcupine.org
> <mailto:wie...@porcupine.org>> wrote:
>>
>> DN Singh:
>> > We some trouble with rediff deliveries, and therefore were
> trying this
>> > combination. While searching the archives, we found that rediff
> does not
>> > like connection caching, and about the recipient_limit option.
> The rate
>>
>> With recipient_limit=1, the Postfix scheduler will try to deliver
>> different recipents in parallel. The concurrency is limited only
>> by the process limit (in master.cf <http://master.cf>) for the
> message delivery
>> transport.
>>
>> You can set that process limit to 1, but that will not change how
>> the rate delay works. As before, it will enforce the delay between
>> deliveries for the same recipient.
>>
>>         Wietse
> Will transport_destination_concurrency work in this case? I am
> asking because I had created this transport for the purpose of
> throttling.
> 


The concurrency is automatically limited to 1 when rate_delay is
non-zero.

(Unless one has also set recipient_limit=1, which changes the
delay+concurrency from per-destination to per-recipient, which is
what started this discussion)



  -- Noel Jones

Reply via email to