Hi Viktor, Each transport has queue list and each queue in that list stands for one destination (nexthop).
Please consider below scenario, transport2 has more queued entries than transport1, but transport 2 will be selected while transport 1 never. The if statement doesn't satisfy the comments. Transport1 ==> queue1 -> queue2 -> queue3 (1 pending) (1 todo) (1 todo) (1 todo) Transport2 ==> queue1 -> queue2 -> queue3 (1 pending) (1 todo) ( 1 todo) (2 todo) Regards, King 2015-05-11 11:28 GMT+08:00 Viktor Dukhovni <postfix-us...@dukhovni.org>: > On Mon, May 11, 2015 at 09:19:43AM +0800, King Cao wrote: > > > > > 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. > > > > 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. > > I repeat. The code is correct as it stands. More messages queued > to be delivered yield more opportunities to schedule a delivery. > > Nothing weird here at all. In particular, with a delivery agent > connection pending, the single "todo" entry is going to be used by > *that* delivery agent when the connection completes, so no additional > agents are scheduled until that happens or more entries become > available. > > Otherwise, under light load we'd wake up two delivery agents for > every entry, only to find that the second delivery agent has nothing > to do. > > I'm going to stop the discussion here. You'll need to figure out > why the code is correct without additional input. > > -- > Viktor. >
