Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <520266D8.1030301@redhat.com>
Date: Wed, 07 Aug 2013 16:25:12 +0100
From: Gordon Sim <gsim@redhat.com>
Organization: Red Hat UK Ltd, Registered in England and Wales under Company
 Registration No. 3798903, Directors: Michael Cunningham (USA), Mark Hegarty
 (Ireland), Matt Parsons (USA), Charlie Peters (USA)
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Creating a queue and bindings from an address in qpid.messaging
 / AMQP 1.0
References: 
 <CAOhBXQ5+ZiaDAz7G0ww4TuYaPfbtfnePrMLHyvh2Cfo5LqoB3A@mail.gmail.com>
In-Reply-To: 
 <CAOhBXQ5+ZiaDAz7G0ww4TuYaPfbtfnePrMLHyvh2Cfo5LqoB3A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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

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

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