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.
