I have considered this solution as well. It sounds simple enough, but once you start thinking about how to implement that, it's not as easy. The per transport scheduling is already fairly complex as it is, with concurrency window and blocker jobs and what not - introducing yet another threshold into the mix doesn't seem to simplify that. I do not say it's impossible - but it seems to be far from trivial to reconsider all the corner cases for me to be willing to undertake that. But maybe it's only because I'm too familiar with the qmgr internals which make it seem more difficult than it really is?
The separate transport OTOH provides clear separation. More importantly, though, it allows you to configure many things like timeouts etc. differently for each first time and retried delivery - something which can't be trivially achieved with single transport. What would be really different when using single transport as opposed to two transports? Wietse pointed out the concurrency limits - anything else comes to mind? Is there something which the separation of the two transports would make worse? I am trying but I can't think of anything right now. I'll keep trying... Another option to consider is to keep the transports separate for most operations but bind them together somehow so some aspects could be shared when such behavior would be desirable. But I am not sure that it is really necessary as of now - and it wouldn't make things simpler either. Anyway, thank you both for your comments so far. Much appreciated. Patrik On 11 May 2013, at 20:11, Viktor Dukhovni <[email protected]> wrote: > On Sat, May 11, 2013 at 07:22:48PM +0200, Patrik Rak wrote: > >> BTW, perhaps I wasn't quite clear above when I said those messages >> dominate the queue. I meant it like their amount in the active queue >> is significant and prevailing, but not that they are really filling >> the active queue entirely. Rather than addressing the >> full-active-queue bottleneck (which you have most likely responded >> to), I was addressing the all-delivery-agents-busy bottleneck. >> Especially in more limited environments where increasing the >> delivery agent limit tenfold or more is not a viable option. > > So you want to desludge the outbound delivery agents, by dedicating > a subset of the process slots to fresh mail. This does not need > a second transport. Rather, just do that within a single transport! > > The queue manager knows how many active deliveries it has scheduled > for each transport. Suppose we give the queue manager a per-transport > upper bound on the number of concurrent deliveries of previously > deferred messages. Then the remaining process slots are for fresh > mail only, and fresh deliveries cannot be starved. > > This largely solves the problem, and is much simpler to configure: > > # Out of a total of $default_process_limit (100), leaving 20 > # for fresh mail. Adjust appropriately when master.cf or > # default_process_limit are changed. > # > smtp_deferred_concurrency_limit = 80 > > If the queue-manager were changed to read master.cf and thus know > delivery agent process limits, then the above could be a percentage, > or a fixed number of slots could be reserved for new mail. > > This is much simpler than configuring additional transports. > > -- > Viktor.
