Hi.
I didn't notice this answer at first.
On 13/11/2019 16:46, Gordon Sim wrote:
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://urldefense.proofpoint.com/v2/url?u=https-3A__qpid.apache.org_releases_qpid-2Dcpp-2D1.39.0_messaging-2Dapi_book_ch01s08.html&d=DwIFaQ&c=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ&r=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4&m=Lyb0wY8rXAJAYxnlSLFpco8Lg0bRT5GLJMVFl7QFAEg&s=Z9apkN2ON-pPhLp6LosUR-xsQ005Tpo3KEksd9GJ8uw&e=
.
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).
OK.
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.
OK. I my software should only ever call fetch() once on a receiver from
nextReceiver().
That said, it is of course always possible that I am missing something
in my analysis of the code.
Fair enough.
Are you able to get any detailed logging from a case where this is
happening? Are you able to reproduce it?
Unfortunately, I'm struggling to reproduce this now. I did resolved some
of performance issues, but don't seem to get the problems I was seeing
even when going back to an older release...
There has been a queue reconfig that could also affect this. I'll
probably revert and test again at some stage, but I'm not able to do
that right now.
- Toralf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
