Hello Gordon,
We cannot control the broker behaviour unfortunately.
Regarding your point -
>>>>There is the concept of a delivery mode, but no way to 'acquire' a copied
>>>>message. For the default 'move' distribution mode, on a shared queue, a
>>>>message will be allocated to one of the available receivers and from that
>>>>point will not be available to any other receiver until the first receiver
>>>>releases it.
How do we ensure the first receiver has released it? Is it invocation of
Session::acknowledge(msg) which makes it available to other receivers?
What difference will it make if we use Receiver::get() instead of
Receiver::fetch() ?
Best Regards,
Rahul
-----Original Message-----
From: Gordon Sim <g...@redhat.com>
Sent: 31 March 2022 10:52
To: users@qpid.apache.org
Subject: Re: QPID C++ Queue handling
AMQP 1.0 doesn't really support what you are trying to do, which if I
understand it correctly, is to have many receivers peek at messages in the
queue and only remove those that are relevant to them. There is the concept of
a delivery mode, but no way to 'acquire' a copied message. For the default
'move' distribution mode, on a shared queue, a message will be allocated to one
of the available receivers and from that point will not be available to any
other receiver until the first receiver releases it.
The better pattern in my opinion is to have the broker filter the messages into
a separate response queue per receiver. Perhaps that is per unique APPId in
your case.
On Thu, Mar 31, 2022 at 9:39 AM rahul.sin...@morganstanley.com
<rahul.sin...@morganstanley.com> wrote:
>
> Hel
> We are using C++ API - qpid-cpp-1.39.0 and qpid-proton-0.34.0 and seems to
> have an issue handling multiple instances of application (using different
> implementations).
> The broker supplies all messages to our entity in 1 Response Queue and there
> are uniqueAPPId to identify the messages received in Response Queue.
>
> However, at times, only 1 instance seems to get these messages. We
> suspect it's the way we retrieve the messages from the queue. Our
> current logic is Using namespace qpid::messaging; Message msg;
> If(Receiver::fetch (msg, Duration(0))) {
> //process the message if unqiueAppId is ours
>
> //Acknowledge the message
> Session::acknowledge(msg);
> }
>
> Is this the correct way of handling the messages form Response Queue?
>
>
> 1. We had a look at description for Receiver::get() and it indicates that
> the message is retrieved from the Receiver's local Queue.
> For Receiver::fetch(), the description says "Retrieves the message
> from Receiver's Subscription. Unlike get(), this message will check with the
> server that there is no message for the subscription this Receiver is serving
> before returning false. Is the Receiver::fetch method popping the message off
> the Response Queue as opposed to Receiver::get () method.
>
> 1. Whats the purpose of Session::acknowledge(msg) ? Does it pop the
> message off the Response Queue.
>
> We want to only pull the message off the queue which are destined to our
> instance. Otherwise, we don't want to remove them since this might affect
> other instances.
>
> Please can you help in throwing some light on how to get this logic right.
>
> Best Regards,
> Rahul
>
> ________________________________
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
> or views contained herein are not intended to be, and do not constitute,
> advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform
> and Consumer Protection Act. If you have received this communication in
> error, please destroy all electronic and paper copies and notify the sender
> immediately. Mistransmission is not intended to waive confidentiality or
> privilege. Morgan Stanley reserves the right, to the extent required and/or
> permitted under applicable law, to monitor electronic communications,
> including telephone calls with Morgan Stanley personnel. This message is
> subject to the Morgan Stanley General Disclaimers available at the following
> link: http://www.morganstanley.com/disclaimers. If you cannot access the
> links, please notify us by reply message and we will send the contents to
> you. By communicating with Morgan Stanley you acknowledge that you have read,
> understand and consent, (where applicable), to the foregoing and the Morgan
> Stanley General Disclaimers.
>
> You may have certain rights regarding the information that Morgan Stanley
> collects about you. Please see our Privacy Pledge
> https://www.morganstanley.com/privacy-pledge for more information about your
> rights.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
commands, e-mail: users-h...@qpid.apache.org
--------------------------------------------------------------------------------
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or
views contained herein are not intended to be, and do not constitute, advice
within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and
Consumer Protection Act. If you have received this communication in error,
please destroy all electronic and paper copies and notify the sender
immediately. Mistransmission is not intended to waive confidentiality or
privilege. Morgan Stanley reserves the right, to the extent permitted under
applicable law, to monitor electronic communications. This message is subject
to terms available at the following link:
http://www.morganstanley.com/disclaimers If you cannot access these links,
please notify us by reply message and we will send the contents to you. By
communicating with Morgan Stanley you consent to the foregoing and to the voice
recording of conversations with personnel of Morgan Stanley.
You may have certain rights regarding the information that Morgan Stanley
collects about you. Please see our Privacy Pledge
https://www.morganstanley.com/privacy-pledge for more information about your
rights.
