Hello Gordon/Robbie,
1. Adding the {node:{type:topic}} to the topic name helps in getting the topic Capability added in the outgoing AMQP frame to broker. However, I still get the same error. Our Code - qpid::messaging::Receiver topic_receiver = session.createReceiver("ID.ExampleTopic; {node:{type:topic}}" "); AMQP FRAMES - ME -> BROKER FRAME: 0 -> @attach(18) [name="ID.ExampleTopic_c1118253-bf96-4379-70ac-721571b25c70", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ID.ExampleTopic", durable=0, timeout=0, dynamic=false, capabilities=:topic], target=@target(41) [address="ID.ExampleTopic", durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] BROKER -> ME FRAME: 0 <- @attach(18) [name="ID.ExampleTopic_c1118253-bf96-4379-70ac-721571b25c70", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, target=@target(41) [address="ID.ExampleTopic"], incomplete-unsettled=false, initial-delivery-count=0] FRAME: 0 <- @detach(22) [handle=0, closed=true, error=@error(29) [condition=:"amqp:unauthorized-access", description="xxxxxxxxxxxxxxxxxxxxxxxxx is not authorized to create: queue://ID.ExampleTopic"]] 1. As per Robbie's suggestion, I have tried adding topic:// in the past as well but the address and name selection gets chopped off from our end (after topic: ) in the outgoing AMQP frame to Broker. Our Code - qpid::messaging::Receiver topic_receiver = session.createReceiver("topic://ID.ExampleTopic; {node:{type:topic}}" "); AMQP FRAMES - ME -> BROKER 0 -> @attach(18) [name="topic:_c1118253-bf96-4379-70ac-721571b25c70", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="topic:", durable=0, timeout=0, dynamic=false, filter={:"subject-filter"=@7756710c6395760 "/ID.ExampleTopic"}, capabilities=:topic], target=@target(41) [address="topic:", durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] BROKER -> ME FRAME: 0 <- @attach(18) [name="topic:_c1118253-bf96-4379-70ac-721571b25c70", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, target=@target(41) [address="topic:"], incomplete-unsettled=false, initial-delivery-count=0] FRAME: 0 <- @detach(22) [handle=0, closed=true, error=@error(29) [condition=:"amqp:unauthorized-access", description="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is not authorized to read from: queue://topic:"]] Is there a way, we can ensure no such chopping happens when the string passed to createReceiver has "//". According to the broker, they should be able to accept both "ID.ExampeTopic" OR "topic://ID.ExampleTopic", however, the former is still not working even after setting topic capability ({node:{type:topic}} , and the later somehow gets truncated and "topic://ID.ExampleTopic" ends up in "topic:". According to them, what should work in JMS (Java equivalent) String dataTopic=" topic://ID.ExampleTopic"; OR "ID.ExampleTopic" String uniqueID="MyUniqueID"; JMSConsumer topicConsumer = context.createDurableConsumer(dataTopic, uniqueID); One thing I noticed is that the "durable" parameter is 0 in our outgoing frames. Was wondering if there is a way to set that upfront while creating the Receiver. ( I have seen durable feature with Message Class in C++ but that comes later) Best Regards, Rahul -----Original Message----- From: Gordon Sim <g...@redhat.com> Sent: 01 July 2021 10:43 To: users@qpid.apache.org Subject: Re: QPID C++ Subscribing to a topic To specify a :topic capability you can use an address of the form "ID.ExampleTopic; {node:{type:topic}}". On Thu, Jul 1, 2021 at 10:10 AM rahul.sin...@morganstanley.com <rahul.sin...@morganstanley.com> wrote: > > Hello, > The broker does not seem to have much understanding of the C++ QPID > Messaging API and is more used to the Java version. All it is suggesting to > ensure that we pass the topic in the format "ID.ExampleTopic". However, > looking at the AMQP frames from Broker, it seems to misinterpret that topic > for a queue, hence there is an unauthorize error reported. ( " is not > authorized to create: queue://ID.ExampleTopic" ) From the QPID API usage > perspective, do I need to invoke something else to make the topic usage > clear. I also experimented with creating a Sender with same topic name but I > get the same error. > > Best Regards, > Rahul > > -----Original Message----- > From: Gordon Sim <g...@redhat.com> > Sent: 30 June 2021 10:01 > To: users@qpid.apache.org > Subject: Re: QPID C++ Subscribing to a topic > > On Wed, Jun 30, 2021 at 9:40 AM rahul.sin...@morganstanley.com > <rahul.sin...@morganstanley.com> wrote: > > After being able to establish the connection with the broker at other end, > > we try to subscribe to a given topic. For this, we create the receiver with > > string mapping to the topic. ( Id.ExampleTopic ), where Id is the > > identifier broker assigned to us and ExampleTopic is the topic. > > We have already sought clarification with the broker about this issue, > > however, we wanted to ensure if the AMQP APIs are being used correctly for > > this and if we need to somehow communicate that we are subscribing for a > > topic. (for example, do we need to add some qualifier to the passed string > > etc. > > > > qpid::messaging::Connection conn(url, options); conn.open(); > > > > qpid::messaging::Session session = conn.createSession(); > > > > qpid::messaging::Receiver topic_receiver = > > session.createReceiver("Code.ExampleTopic"); > > > If you are using AMQP 1.0, and the broker treats the creation of a receiver > with that pattern as a subscription on a topic, then the client does not > require any further configuration. > > ________________________________ 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.