Set destination from Qpid Proton Client

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Set destination from Qpid Proton Client

MattR
Hello,

I am upgrading our system's Qpid setup to the latest and greatest of each
Proton, JMS, and Broker-J versions (coming off REALLY old non-Proton Qpid).
I was hoping someone might be able to tell me if it is possible to set the
destination of a queue when setting up the receiver. Broker-J conveniently
creates the queue if it doesn't exist. I can set it to be a durable queue by
providing a DurableSubscription() in the options of the receiver I am
making. I can even get the bindingKey of the queue set to what I want.
However, I can't seem to figure out how to tell Broker-J to set the
destination attribute of the queue, short of having to use the REST API. Our
preferred setup for queues is to have the destination and bindingKey the
same so that we can simply have multiple subscribers/consumers attached to a
single queue. I can't seem to find anything in the docs or api (specifically
for Proton Python at the moment), and I apologize in advance if I am
overlooking those details.

Thanks,

Matt R.



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Set destination from Qpid Proton Client

Robbie Gemmell
Administrator
If you are just looking to consume from a particular named queue, you
provide the queue name as the address for the consumer.

If you are looking to do something more complicated youll perhaps need
to elaborate a bit more on what that is.

On Fri, 31 May 2019 at 15:23, MattR <[hidden email]> wrote:

>
> Hello,
>
> I am upgrading our system's Qpid setup to the latest and greatest of each
> Proton, JMS, and Broker-J versions (coming off REALLY old non-Proton Qpid).
> I was hoping someone might be able to tell me if it is possible to set the
> destination of a queue when setting up the receiver. Broker-J conveniently
> creates the queue if it doesn't exist. I can set it to be a durable queue by
> providing a DurableSubscription() in the options of the receiver I am
> making. I can even get the bindingKey of the queue set to what I want.
> However, I can't seem to figure out how to tell Broker-J to set the
> destination attribute of the queue, short of having to use the REST API. Our
> preferred setup for queues is to have the destination and bindingKey the
> same so that we can simply have multiple subscribers/consumers attached to a
> single queue. I can't seem to find anything in the docs or api (specifically
> for Proton Python at the moment), and I apologize in advance if I am
> overlooking those details.
>
> Thanks,
>
> Matt R.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Set destination from Qpid Proton Client

MattR
My apologies for lacking detail. I'm certainly not trying to make anything
more complicated than I need to.

From my understanding, there is no way to create a queue from the client.
However, with Broker-J, if trying to subscribe to a non-existent queue, then
Broker-J will create one for you; albeit with a mangled name for the queue
(e.g. qpidsub_/ID:....). The mangled name was my problem as I needed the
name to match the binding key so as to prevent unnecessary extra queues
(i.e. a queue with name "test_queue" could be found in the amq.direct
exchange with destination and bindingKey both set to "test_queue"). I have
gotten around this by simply utilizing the REST api to create the queue and
exchange binding on the fly (based on our current code, this used to be
possible using the old Python Qpid api's session.declare_queue and
session.exchange_bind, respectively).

My issue now is that I, essentially, need to be able to do the following in
Proton:

# Declare a local queue to which we subscribe the reply-to queue
localQueueName = "producerLocalQueue_" + session.name
localQueue = session.incoming(localQueueName)
session.message_subscribe(queue=replyQueueName,
                          destination=localQueueName)
localQueue.start()

(ref: https://www.linuxjournal.com/article/10379)

I can't seem to figure out how to mimic the message_subscribe behavior. Is
that simply creating another receiver passing the reply queue as the source
and local queue as the target or name?

I apologize in advance if I'm making this over complicated or missing
something from the docs/api that explain this.

Thanks,

Matt R.



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Set destination from Qpid Proton Client

Justin Ross-3
This still looks like a normal receive scenario to me.  Since you've
created the queue using the REST API, all you need to do is use the name of
the queue in your client code:

https://github.com/ssorj/equipage/blob/master/qpid-proton-python/receive.py#L40
-
self.address here would be the name of your queue

The main Proton example for this has the same thing, but it's part of a URL:

https://github.com/apache/qpid-proton/blob/master/python/examples/simple_recv.py#L34
-
The path part of self.url would be the name of your queue

There is no need to create a distinct, explicitly named local queue with
Proton.  The library provides that through its API.

Related docs:

http://qpid.apache.org/releases/qpid-proton-0.28.0/proton/python/book/tutorial.html
http://qpid.apache.org/releases/qpid-proton-0.28.0/proton/python/api/proton._reactor.Container-class.html#create_receiver



On Fri, Jun 7, 2019 at 3:47 PM MattR <[hidden email]> wrote:

> My apologies for lacking detail. I'm certainly not trying to make anything
> more complicated than I need to.
>
> From my understanding, there is no way to create a queue from the client.
> However, with Broker-J, if trying to subscribe to a non-existent queue,
> then
> Broker-J will create one for you; albeit with a mangled name for the queue
> (e.g. qpidsub_/ID:....). The mangled name was my problem as I needed the
> name to match the binding key so as to prevent unnecessary extra queues
> (i.e. a queue with name "test_queue" could be found in the amq.direct
> exchange with destination and bindingKey both set to "test_queue"). I have
> gotten around this by simply utilizing the REST api to create the queue and
> exchange binding on the fly (based on our current code, this used to be
> possible using the old Python Qpid api's session.declare_queue and
> session.exchange_bind, respectively).
>
> My issue now is that I, essentially, need to be able to do the following in
> Proton:
>
> # Declare a local queue to which we subscribe the reply-to queue
> localQueueName = "producerLocalQueue_" + session.name
> localQueue = session.incoming(localQueueName)
> session.message_subscribe(queue=replyQueueName,
>                           destination=localQueueName)
> localQueue.start()
>
> (ref: https://www.linuxjournal.com/article/10379)
>
> I can't seem to figure out how to mimic the message_subscribe behavior. Is
> that simply creating another receiver passing the reply queue as the source
> and local queue as the target or name?
>
> I apologize in advance if I'm making this over complicated or missing
> something from the docs/api that explain this.
>
> Thanks,
>
> Matt R.
>
>
>
> --
> Sent from:
> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>