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.
