Hi Viktor, I was reading the documentation and found out something very interesting.
If I use mumble_destination_concurrency_limit = 1, the destination is a recipient not a domain. Since I'm trying to control the throughput per destination domain, it is necessary to use destination_concurrency_limit > 1, in this case I believe that if I use mumble_destination_concurrency_limit = 2 would be good for this issue. default_destination_concurrency_limit (default: 20) The default maximal number of parallel deliveries to the same destination. This is the default limit for delivery via the lmtp(8), pipe(8), smtp(8) and virtual(8) delivery agents. With per-destination recipient limit > 1, a destination is a domain, otherwise it is a recipient. Is this correct? Thanks in advance. Att. -- Rafael Azevedo | IAGENTE Fone: 51 3086.0262 MSN: raf...@hotmail.com Visite: www.iagente.com.br Em 07/01/2013, às 14:25, Viktor Dukhovni <postfix-us...@dukhovni.org> escreveu: > On Mon, Jan 07, 2013 at 11:34:45AM -0200, Rafael Azevedo - IAGENTE wrote: > >> This is what I'm trying to do: >> >> - I need to have only one process to this transport's queue. > > mumble_destination_concurrency_limit = 1 > >> - This queue must respect the destination's policy, so I can't >> have more than 20 opened connections in 10 minutes timeframe. Thats >> why I want to use connection cache. > > The connection cache is used automatically when there is a backlog > of mail to the destination. You are defeating the connection cache > by enforcing a rate limit of 1, which rate limits deliveries, not > connections. DO NOT set a rate limit. > >> According to my configuration, I'm having only one process for >> this transport, also limiting the sending time, holding down delivery >> process, waiting 1 second for each sent message before sending >> another one. > > Instead of setting a process limit of 1, you can just specify an > explicit nexthop for the domains whose concurrency you want to > aggregate: > > example.com mumble:example.com > example.net mumble:example.com > example.edu mumble:example.com > ... > > This should the queue manager schedule deliveries to these domains > as it will combine the queues for all the domains that use the > transport into a single queue (while using the MX records for > a suitably chosen single domain). > >> And since this transport handles only specific domains, I really >> don't have to worry about receiver policies, because they told me >> to send as much as I can using the same connection, avoiding opening >> one connection per message. > > Don't enable rate delays. Do specify a common nexthop for all domains > that share the transport. Don't mess with the connection cache timers. > > -- > Viktor.
