With a queue, only 1 consumer gets a particular message at a time
until the message is consumed. If a consumer is given a message from
the queue (which may occur even before calling get or fetch, if there
is any prefetching being allowed, 'capacity' I think in the old C++
bits terminology) then no other consumer can get it while that
consumer has it, and if you fetch/get it from the consumer but dont
"//process the message if unqiueAppId is ours" as it is not yours,
then still no other consumer can get it, unless the one that did
releases its hold on the message (at which point that consumer may
even get it again).
The acknowledge call acknowledge/accepts consumption of the message,
i,e marks it consumed so it can be removed from the queue. If you
actually acknowledge a message then it is consumed and removed from
the queue, whether you actually processed it or not.
If you only want certain consumers to get certain messages, and other
consumers not to get them, then you would probably want to separate
them at the broker so they only ever go to the consumer of interest.
Either having a response queue for each app (as Gordon has now said
and you have ruled out, before I got back to finishing this mail
hehe), or by providing a message selector when creating consumers so
they can each only ever get the messages actually matching what they
want from the shared response queue.
The qpid-cpp C++ client is not being actively developed at this point,
so you should also consider looking at the Proton C++ client binding.
On Thu, 31 Mar 2022 at 09:31, 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
