On 11.5.2015 3:19, King Cao wrote:
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.
I am afraid you are missing entirely how the pending counter works.
First, there is no pending connection. Then, we look up for some
transport which has some todo entry available. Once we find it, we
initiate the asynchronous connection to the delivery agent process. At
that point, we increase the pending counter, which is going to be
satisfied by the todo entry we have just found.
Then we look again, and see if there is more transports eligible for
delivery. At this point, if the transport has already one connection
pending, it has to have at least two todo entries to be eligible. And
later on, if it has two delivery connections pending, it is not eligible
at all, no matter how many todo entries it has, because we don't want to
have more than two delivery connections pending - doing that actually
hurts the performance, it doesn't improve it.
Once the connection to the delivery agent process completes, the pending
counter decreases, the todo entry becomes busy entry, the delivery agent
starts the message delivery, and the transport is eligible for selection
again. That is, the transport can have hundreds of delivery agents
connected to it, each delivering one busy entry, but only two pending
connections at a time. This is to guard against spawning insane number
of delivery agents at the same time if the system can't keep up spawning
them.
Patrik
P.S. If this explanation doesn't help, I am afraid I'll just have to
second Victor's words that you are on your own.
