On 12/11/2019 6:35 pm, Toralf Lund wrote:
Good evening, all.
I have an application that uses qpid::Session::nextReceiver() to handle
data from 3 or 4 different AMQP 0-10 message queues - it follows the
pattern from
https://qpid.apache.org/releases/qpid-cpp-1.39.0/messaging-api/book/ch01s08.html.
Question: If multiple receivers are ready when nextReceiver() is called,
which one should I expect to be returned? Is there a well-defined order
or priority?
The destinations returned should be in the order the messages are
received, providing you are only fetching a single message after each
return from nextReceiver(). (And are not otherwise interacting with
receivers on the session).
In more detail, the way the code works is that there is a lower layer
that the messaging API call on, which should return frames for the
session in the order they are read from the wire.
However there are different ways the messaging api provides to interact
with this. The messaging session maintains a list of frames received
from the lower layer that have not been 'handled' in some way by the
application. E.g. if you have two receivers, are receiving messages for
each, but call fetch in a loop on just one of them, then the messages
for the other receiver will be kept in this queue until that receiver
fetches.
The nextReceiver() call will return the receiver associated with the
first message in that list (retrieving one from the lower layer if that
list is empty). If you then call fetch on that receiver, it should
remove that message and return it.
What if new messages keep appearing, so a given call will
never, or rarely, see just one ready receiver?
I think my application sometimes, due to a performance issue that's yet
to be resolved, gets into that situation, i.e. more than one receiver is
ready, and at least one more gets ready before the subsequent
nextReceiver() call. That means the system is not able to handle all
incoming messages, but it may look like this mostly affects only one
receiver - it's as if nextReceiver() almost never gets to it because
data keeps appearing on the others, or something. The queue associated
with the receiver happens to get new data at a slightly lower rate than
some of the others, and its message are also *much* larger. Does that
make any sense at all?
If when you get a receiver from nextReceiver() you keep calling fetch on
that, then it would mean that messages received on other receivers would
be queued up in the sessions list awaiting processing by a call to fetch
on those receivers.
If you only make a single fetch() call on the receiver returned from
nextReceiver(), then return to nextReceiver() then I can't see any
reason why one receiver that is receiving messages would not be
returned. That said, it is of course always possible that I am missing
something in my analysis of the code.
Are you able to get any detailed logging from a case where this is
happening? Are you able to reproduce it?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
