qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Creating a queue and bindings from an address in qpid.messaging / AMQP 1.0
Date Thu, 08 Aug 2013 08:44:50 GMT
On 08/07/2013 10:27 PM, Jakub Scholz wrote:
> 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:
>
> myresponse_queue_1;
> {
>          create: always,
>          assert: never,
>          node:
>          {
>                  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?

Yes please, a JIRA would be great!

One other point to mention here is that though the properties are 
conveyed by a standard mechanism, they are as yet only understood by 
qpidd. For the qpid.xxx options this is pretty uch the same situation as 
with 0-10 (i.e. standard extension point used, the extension itself is 
not yet standardised).

For autodelete, there *is* a similar standard property in AMQP 1.0, the 
lifetime-policy. In the address the values for that are delete-on-close, 
delete-if-unused, delete-if-empty or delete-if-unused-and-empty (these 
are sent as the standard 1.0 policy types on the wire). This would be 
more portable between brokers. (Obviously it doesn't address the sizing 
policy for which there is no standard yet).

>>   - 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?

Yes. The only way to have a binding created when attaching a link is to 
create a receiver link from an exchange in which case the subscription 
queue is created automatically and bound based on any supplied filter 
(including the subject).

However there is no way to configure most aspects of the subscription 
queue through the address (its name, its durability, its expiration and 
whether it can be shared by multiple receivers can be set). That's why I 
had to bring in the notion of a topic. That does have the advantage of 
allowing the configuration for subscription queues to be controlled 
centrally. On the other hand it requires an extra configuration step to 
do so.

> 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.

The client application could do that explicitly by setting the container-id.

I agree that we could probably have a more meaningful default though.

My one concern about using userid on its own as the default container-id 
is where multiple processes authenticate as the same user. These would 
need to ensure any explicit link names were unique. It also seems 
somewhat incorrect to identify them as the same container.

What about a combination of the userid and some other details more 
unique to the process or connection ( e.g. perhaps ip & port)? That 
would be more meaningful but also accurate by default even if multiple 
processes authenticate as the same user.

> 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?

Yes, please! Thanks!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message