qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Creating a queue and bindings from an address in qpid.messaging / AMQP 1.0
Date Wed, 07 Aug 2013 21:27:01 GMT
Hi Gordon,

Thanks for your answer ...

On Wed, Aug 7, 2013 at 5:25 PM, Gordon Sim <gsim@redhat.com> wrote:

> On 08/07/2013 03:34 PM, Jakub Scholz wrote:
>> Is there some way how to
>> - create a queue with some specific options
> Yes.
> To begin with, there are two ways in which a node can be created. One is
> the usual 'create' option. Over 1.0 however this will tie you to qpidd as
> there is no standard way to have a node created _with_a_ specific_name_ in
> response to attachment of a link.
> The other is to set the node name in the address to '#' (i.e. a single
> pound or hash character). This form uses a standard AMQP 1.0 mechanism and
> so is recommended for things like dynamically created response queues. The
> broker will assign a name, and that can be retrieved after the
> receiver/sender is established via Receiver::getAddress()/
> Sender::getAddress().
> To set specific options for the node you can put them in a properties map
> in the *node*. The x-declare in the node is recognised as well to ease
> transition.
I assume you meant something like this:

        create: always,
        assert: never,
                durable: false,
                properties: {
                        auto-delete: true,
                        exclusive: true,
                        'qpid.max_count': 1000,
                        'qpid.max_size': 1000000,
                        'qpid.policy_type': ring

That indeed seems to be working. Although, interestingly enough the
auto-delete queue doesn't autodelete with AMQP 1.0 & exclusive=true (0.24
RC1). Is taht a known problem or should I enter JIRA?

>  - bind a queue from the address?
> The only way to do this through addressing is where the node is an
> exchange and you are creating a receiver. In this case a queue will be
> automatically created and bound.
> However, there is no obvious way to pass configuration for this
> subscription queue. So in qpidd I have created the concept of a 'topic'. A
> topic is an exchange along with some default subscription queue settings.
> You create one of these using QMF or a command line tool (such as qpidt
> under tests in svn) and then you use that as the node name to your receiver.
> The name of the subscription queue is formed by joining the container-id
> of the connection and the link name (both default to UUIDs, both can be set
> to anything you like, but each link must have a unique name within the
> scope of the container-id).
So, if I understand you correctly, we can't have both in one address.
Either custom queue or the binding, right? I have to say that the concept
of topics is definitely interesting. I have to think about how to utilize
it in our setup.

>  Or is the only option to first create the queue & binding
>> using QMF?
>> I assume the second might be where the legacy filters might help. But I
>> have no idea how to use them and there don't seem to be much documentation
> For direct and topic exchanges controlling the binding is simple. It can
> be done through the subject in the address. So creating a receiver with
> address my-exchange/my-key will bind the subscription queue to my-exchange
> with my-key.
> As above, and assuming you are using qpidd, in order to configure the
> subscription queue you need to create a topic, e.g.
> qpidt create topic my-topic exchange=response qpid.max_count=1000
> qpid.max_size=1000000 qpid.policy_type=ring
> and then create the receiver using e.g.:
>   my-topic/response.ABCFR_**ABCFRALMMACC1.response_queue_1
> The act of creating a receiver will create the subscription queue using
> the defaults specified for the topic and then that queue will be bound to
> the response exchange using the key 'response.ABCFR_ABCFRALMMACC1.**
> response_queue_1'.
> You can specify the name of the link in the address if desired, but unlike
> in 0-10, this will only form part of the name of the queue. It will be
> prefixed with the container-id (since AMQP 1.0 requires that combination to
> uniquely identify the link). The container-id can be specified as a
> connection option.
> Does this make sense?
This aspect is a bit unfortunate. Since we are running the broker with many
customers connected, we need to have a clear distinction which queue
belongs to which customer. Naming thinks after UUIDs isn't much useful
here. It would be great to be able to better configure this - for example
by setting some prefix based on the authenticated user name.

I noticed one more bug - trying to delete a non-existent topic with qpidt
seems to crash the broker.
I guess I can enter a JIRA for that as well, or?

Thanks & Regards

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message