Hi Victor, The weird thing is that if queue->todo_refcount = 2, the queue will be satisfied but if queue->todo_refcount = 1, the queue is not satisfied. So when we have one pending delivery agent connection, if one queue have two todo tasks, the related transport will be selected, but if one queue just have one todo tasks, the related transport won't be selected.
Regards, King 2015-05-09 13:17 GMT+08:00 Viktor Dukhovni <postfix-us...@dukhovni.org>: > On Sat, May 09, 2015 at 11:27:55AM +0800, King Cao wrote: > > > I went through the qmgr source code and found odd logic, from the > comments > > we can know it will stop until we run out of "todo" entries. However the > > implementation is: > > > > if ((need -= MIN5af51743e4eef(queue->window - queue->busy_refcount, > > queue->todo_refcount)) <= 0) > > > > Suppose transport->pending is 1, so the value of need is 2 (pending+1), > > Which means that we're in the process of making an asynchronous > connection to the transport to request a delivery. > > > queue->window is 5 by default (initial destination concurrency). Suppose > > there is one todo entry and one busy entry, so min(queue->window - > > queue->busy_refcount, queue->todo_refcount) is 1, which cause the > > invalidation of if statement. So even there is one todo entry, but this > > queue is still not satisfied. > > That's correct, the todo entry will be allocated to the pending > connection when it completes. > > > > PS: QMGR_TRANSPORT_MAX_PEND has changed from 1 to 2 before, not sure if > > it's side-effect of this change. > > To allow for more than one pending connection at a time, which > improves queue manager throughput under extreme message rates > (thousands per second, when benchmarking with RAM-disk queues). > > The code is correct. > > -- > Viktor. >
