On Wed, Sep 12, 2012 at 11:57:36PM +0530, DN Singh wrote:
> On Sep 11, 2012 8:43 PM, "Wietse Venema" <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) 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.
>
> Will transport_destination_concurrency work in this case? I am asking
> because I had created this transport for the purpose of throttling.
The concurrency limit always works, what changes is how it is measured.
For transports with a recipient limit of 1, the delivery destination
is the recipient, not the nexthop (typically the recipient domain).
Thus when the recipient limit is 1, both concurrency and rate delays
are per-recipient, since each recipient is a distinct destination.
Otherwise, the concurrency and rate delays are measured per
destination domain (or explicit transport nexthop).
What you're seeing is not non-working behaviour, you're seeing
differently-working behaviour wherein the notion of "destination"
for concurrency controls changes to include the recipient address
localpart.
--
Viktor.
