Hi Gordon, Thanks for your answer ...
On Wed, Aug 7, 2013 at 5:25 PM, Gordon Sim <[email protected]> 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? > > - 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 Jakub
