You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2019/11/12 18:35:00 UTC
Order of receivers from qpid::Session::nextReceiver() (with high
load)
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? 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?
Thanks.
- Toralf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [External] Re: Order of receivers from
qpid::Session::nextReceiver() (with high load)
Posted by Toralf Lund <to...@pgs.com>.
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Order of receivers from qpid::Session::nextReceiver() (with high
load)
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org