You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jakub Scholz <ja...@scholz.cz> on 2013/08/07 16:34:06 UTC
Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Hi,
I played a bit with the qpid.messaging API and its AMQP 1.0 support. I
tried to use AMQP 1.0 for my request/response application which creates a
temporary queue with some specific options (policy type, max size and max
count) and bind it to an exchange. With AMQP 0.10, I was using following
address when creating the receiver and it was working fine:
<ResponseQueueName>;
{
create: receiver, assert: never,
node:
{
type: queue,
x-declare:
{
auto-delete: true,
exclusive: false,
arguments:
{
'qpid.policy_type': ring,
'qpid.max_count': 1000,
'qpid.max_size': 1000000
}
},
x-bindings:
[
{
exchange: '<ResponseExchange>',
queue: '<ResponseQueueName>',
key: '<ResponseRoutingKey>'
}
]
}
}
However, with AMQP 1.0, I get the error that the x-binding is not
supported. I also tried another address which worked with AMQP 0.10 and
does the same:
response / response.ABCFR_ABCFRALMMACC1.response_queue_1;
{
create: never,
link:
{
name: 'response.ABCFR_ABCFRALMMACC1.response_queue_1',
durable: false,
x-declare:
{
auto-delete: true,
exclusive: true,
arguments :
{
'qpid.max_count': 1000,
'qpid.max_size': 1000000,
'qpid.policy_type': ring
}
}
}
}
but here the x-declare is not supported.
Is there some way how to
- create a queue with some specific options
- bind a queue
from the address? 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
Thanks & Regards
Jakub
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 04:20 PM, Jakub Scholz wrote:
>> I would say it is a bug in that the durable option should be removed from
>> the properties to lessen the confusion.
>>
>>
> Do you want me to enter a JIRA for that?
That would be great, thanks!
> One additional point I noticed ... the topics automatically force the
> created queues to be exclusive ... is that intentional?
The subscription queue should be exclusive whether the node is a topic
or an exchange unless it is explicitly requested to be shared (via a
shared capability in the node).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
> I would say it is a bug in that the durable option should be removed from
> the properties to lessen the confusion.
>
>
Do you want me to enter a JIRA for that?
One additional point I noticed ... the topics automatically force the
created queues to be exclusive ... is that intentional?
Thanks & Regards
Jakub
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 02:19 PM, Jakub Scholz wrote:
> One more question to the qpidt ... when I create a durable topic using this
> command:
>
> qpidt create topic x durable=true exchange=response qpid.max_count=1000
> qpid.max_size=1000000 qpid.policy_type=ring
>
> It makes the topic durable, but it also adds the durability to the
> properties, although it is ignored with the actual subscription queue
> created for this topic when the receiver connects:
>
> Object of type:
> org.apache.qpid.broker:topic:_data(6182b36f-9f09-4118-2881-fb69e5355628)
> Attribute 185
>
> ======================================================================================================================================================
> name x
> exchangeRef 145
> durable True
> properties {u'qpid.max_size': u'1000000', u'durable': u'true',
> u'qpid.policy_type': u'ring', u'qpid.max_count': u'1000', u'exchange':
> u'response'}
>
> Is that excepted behavior or is that a bug?
I can certainly see that it is confusing. The durability of the topic
is distinct from the durability of the link (which can be set through
the durable link property in the address with which the receiver is
created).
I would say it is a bug in that the durable option should be removed
from the properties to lessen the confusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
One more question to the qpidt ... when I create a durable topic using this
command:
qpidt create topic x durable=true exchange=response qpid.max_count=1000
qpid.max_size=1000000 qpid.policy_type=ring
It makes the topic durable, but it also adds the durability to the
properties, although it is ignored with the actual subscription queue
created for this topic when the receiver connects:
Object of type:
org.apache.qpid.broker:topic:_data(6182b36f-9f09-4118-2881-fb69e5355628)
Attribute 185
======================================================================================================================================================
name x
exchangeRef 145
durable True
properties {u'qpid.max_size': u'1000000', u'durable': u'true',
u'qpid.policy_type': u'ring', u'qpid.max_count': u'1000', u'exchange':
u'response'}
Is that excepted behavior or is that a bug?
Thanks & Regards
Jakub
On Thu, Aug 8, 2013 at 3:07 PM, Jakub Scholz <ja...@scholz.cz> wrote:
>
> What about keeping the UUID but prefixing it with any authenticated
>> userid? That at least means the userid will by default be in the
>> subscription queue names (and easily deducible from container-id), but by
>> default will always be unique also.
>>
>>
> That is definitely better than UUID only.
>
>
>>
>> I'm also wondering whether this isn't also a question of 100 people
>>> having
>>> 100 opinions - we might have problem finding something what would fit
>>> everyone.
>>>
>>
>> Indeed. However we are only talking about the default. An explicit scheme
>> can always be used by setting the connection option. Obviously this
>> requires clients to adhere to some defined scheme. That seems unavoidable
>> (but would be nice to be able to use ACL to enforce it perhaps, i.e.
>> restrict use of particular container id patterns by user?)
>>
>>
> Yes, that would be very nice. In relation to the default container naming
> as suggested above, without the ACL you can easily "fake" the container
> name to another user.
>
> Thanks & Regards
> Jakub
>
Updated notes for AMQP 1.0 support in qpidd and qpid::messaging (was
Re: Creating a queue and bindings from an address in qpid.messaging / AMQP
1.0)
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 05:46 PM, Jakub Scholz wrote:
> Are these AMQP 1.0 related changes documented somewhere?
Not properly yet. I've been sending out some rough notes to the user
list (updated version attached). I need to spend some time figuring out
where and how to make the information more accessible.
Perhaps while I'm trying to find that time, I should just check it in
alongside the other READMEs in the cpp tree? Would anyone object?
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
Ah, nice, with the shared capability it is as I wanted it :-)
Are these AMQP 1.0 related changes documented somewhere? The trunk
documentation section on the website doesn't contain the C++ broker docu
... only the Java broker docu and the Programming guide (which doesn't seem
to mention 1.0 anyway).
On Thu, Aug 8, 2013 at 6:14 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 08/08/2013 05:04 PM, Jakub Scholz wrote:
>
>> I entered both JIRAs - they are QPID-5060 and QPID-5061 (although I guess
>> you can see them in the developer mailing list anyway).
>>
>
> Thanks again, Jakub! I appreciate you taking the time to try it out and
> report back on the problems.
>
>
> My concern there is that from an AMQP 1.0 perspective it is entirely legal
>>
>>> to use the same link name with a different container-id and for those
>>> uses
>>> not to interfere with each other.
>>>
>>>
>>> Yes, that might be a complication. I might be changing the original
>> concept
>> too much to fit my purpose :-o
>>
>>
> Note that if you want to *share* a subscription queue, you can request the
> shared capability in which case only the link name is used for the queue.
> (This is an extension to 1.0)
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 05:04 PM, Jakub Scholz wrote:
> I entered both JIRAs - they are QPID-5060 and QPID-5061 (although I guess
> you can see them in the developer mailing list anyway).
Thanks again, Jakub! I appreciate you taking the time to try it out and
report back on the problems.
> My concern there is that from an AMQP 1.0 perspective it is entirely legal
>> to use the same link name with a different container-id and for those uses
>> not to interfere with each other.
>>
>>
> Yes, that might be a complication. I might be changing the original concept
> too much to fit my purpose :-o
>
Note that if you want to *share* a subscription queue, you can request
the shared capability in which case only the link name is used for the
queue. (This is an extension to 1.0)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
I entered both JIRAs - they are QPID-5060 and QPID-5061 (although I guess
you can see them in the developer mailing list anyway).
My concern there is that from an AMQP 1.0 perspective it is entirely legal
> to use the same link name with a different container-id and for those uses
> not to interfere with each other.
>
>
Yes, that might be a complication. I might be changing the original concept
too much to fit my purpose :-o
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 04:09 PM, Jakub Scholz wrote:
> Sure, why not. Currently we also don't have any named subscriptions based
> on user ID with 0.10 - only named queues and we never had a problem with it.
>
> In the ATTACH command, the client sends only the link name from the
> address. Can't we leave the link names as they are right now (i.e.
> container-id + link name), but name the queue only by the link name and
> leave the container id out of it? The queue names are well protected by
> existing ACL rules and every user can easily specify it in the address. The
> problem with the uniqueness of the queue name will be left to the user, but
> that will be not different from creating the queues from the address in
> AMQP 0.10.
My concern there is that from an AMQP 1.0 perspective it is entirely
legal to use the same link name with a different container-id and for
those uses not to interfere with each other.
> Regards
> Jakub
>
> PS: I tried to connect twice a client with the same container ID & link
> name ... the client gets exception about exclusive queue which already has
> an consumer. But what is more important, the broker crashes. I guess I can
> enter another JIRA ...
Oops, yes please!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
Sure, why not. Currently we also don't have any named subscriptions based
on user ID with 0.10 - only named queues and we never had a problem with it.
In the ATTACH command, the client sends only the link name from the
address. Can't we leave the link names as they are right now (i.e.
container-id + link name), but name the queue only by the link name and
leave the container id out of it? The queue names are well protected by
existing ACL rules and every user can easily specify it in the address. The
problem with the uniqueness of the queue name will be left to the user, but
that will be not different from creating the queues from the address in
AMQP 0.10.
Regards
Jakub
PS: I tried to connect twice a client with the same container ID & link
name ... the client gets exception about exclusive queue which already has
an consumer. But what is more important, the broker crashes. I guess I can
enter another JIRA ...
On Thu, Aug 8, 2013 at 4:34 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 08/08/2013 02:07 PM, Jakub Scholz wrote:
>
>> What about keeping the UUID but prefixing it with any authenticated
>>> userid? That at least means the userid will by default be in the
>>> subscription queue names (and easily deducible from container-id), but by
>>> default will always be unique also.
>>>
>>>
>>> That is definitely better than UUID only.
>>
>>
>>
>>> I'm also wondering whether this isn't also a question of 100 people
>>> having
>>>
>>>> 100 opinions - we might have problem finding something what would fit
>>>> everyone.
>>>>
>>>>
>>> Indeed. However we are only talking about the default. An explicit scheme
>>> can always be used by setting the connection option. Obviously this
>>> requires clients to adhere to some defined scheme. That seems unavoidable
>>> (but would be nice to be able to use ACL to enforce it perhaps, i.e.
>>> restrict use of particular container id patterns by user?)
>>>
>>>
>>> Yes, that would be very nice. In relation to the default container
>> naming
>> as suggested above, without the ACL you can easily "fake" the container
>> name to another user.
>>
>
> Maybe the container id is the wrong thing to focus on. Maybe I should
> change the naming scheme for the subscriptions queues to be
> userid.container-id.link-name? That way there is no way to fake the
> association to user in the queue name, and from your original mail it
> sounds like that might be the most important part?
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 02:07 PM, Jakub Scholz wrote:
>> What about keeping the UUID but prefixing it with any authenticated
>> userid? That at least means the userid will by default be in the
>> subscription queue names (and easily deducible from container-id), but by
>> default will always be unique also.
>>
>>
> That is definitely better than UUID only.
>
>
>>
>> I'm also wondering whether this isn't also a question of 100 people having
>>> 100 opinions - we might have problem finding something what would fit
>>> everyone.
>>>
>>
>> Indeed. However we are only talking about the default. An explicit scheme
>> can always be used by setting the connection option. Obviously this
>> requires clients to adhere to some defined scheme. That seems unavoidable
>> (but would be nice to be able to use ACL to enforce it perhaps, i.e.
>> restrict use of particular container id patterns by user?)
>>
>>
> Yes, that would be very nice. In relation to the default container naming
> as suggested above, without the ACL you can easily "fake" the container
> name to another user.
Maybe the container id is the wrong thing to focus on. Maybe I should
change the naming scheme for the subscriptions queues to be
userid.container-id.link-name? That way there is no way to fake the
association to user in the queue name, and from your original mail it
sounds like that might be the most important part?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
> What about keeping the UUID but prefixing it with any authenticated
> userid? That at least means the userid will by default be in the
> subscription queue names (and easily deducible from container-id), but by
> default will always be unique also.
>
>
That is definitely better than UUID only.
>
> I'm also wondering whether this isn't also a question of 100 people having
>> 100 opinions - we might have problem finding something what would fit
>> everyone.
>>
>
> Indeed. However we are only talking about the default. An explicit scheme
> can always be used by setting the connection option. Obviously this
> requires clients to adhere to some defined scheme. That seems unavoidable
> (but would be nice to be able to use ACL to enforce it perhaps, i.e.
> restrict use of particular container id patterns by user?)
>
>
Yes, that would be very nice. In relation to the default container naming
as suggested above, without the ACL you can easily "fake" the container
name to another user.
Thanks & Regards
Jakub
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
On 08/08/2013 12:03 PM, Jakub Scholz wrote:
> Hi Gordon,
>
> - The auto-delete problem is entered as QPID-5053
> - The qpidt problem is entered as QPID-5054
Marvellous, thanks again! I'll get those fixed asap.
>> 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.
>>
>
> I agree with your concern. That is why defining the container-id in the
> connection options IMHO solves the problem only partially. I can specify
> there whatever I want, but then if I run the application multiple times it
> wont be unique.
>
>
>> 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.
>>
>>
> In a large AMQP networks, will the IP address be really unique? I assume it
> can happen that you have two different clients using the same IP address
> internally in their local networks (which is what the AMQP client would
> use) and connecting to the broker outside of their network over some NAT.
> So it might be only "more unique" than the user ID alone, but not really
> unique.
What about keeping the UUID but prefixing it with any authenticated
userid? That at least means the userid will by default be in the
subscription queue names (and easily deducible from container-id), but
by default will always be unique also.
> I'm also wondering whether this isn't also a question of 100 people having
> 100 opinions - we might have problem finding something what would fit
> everyone.
Indeed. However we are only talking about the default. An explicit
scheme can always be used by setting the connection option. Obviously
this requires clients to adhere to some defined scheme. That seems
unavoidable (but would be nice to be able to use ACL to enforce it
perhaps, i.e. restrict use of particular container id patterns by user?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Gordon,
- The auto-delete problem is entered as QPID-5053
- The qpidt problem is entered as QPID-5054
> 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.
>
I agree with your concern. That is why defining the container-id in the
connection options IMHO solves the problem only partially. I can specify
there whatever I want, but then if I run the application multiple times it
wont be unique.
> 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.
>
>
In a large AMQP networks, will the IP address be really unique? I assume it
can happen that you have two different clients using the same IP address
internally in their local networks (which is what the AMQP client would
use) and connecting to the broker outside of their network over some NAT.
So it might be only "more unique" than the user ID alone, but not really
unique.
I'm also wondering whether this isn't also a question of 100 people having
100 opinions - we might have problem finding something what would fit
everyone.
Thanks & Regards
Jakub
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
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 <gs...@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
Re: Creating a queue and bindings from an address in qpid.messaging /
AMQP 1.0
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Gordon,
Thanks for your answer ...
On Wed, Aug 7, 2013 at 5:25 PM, Gordon Sim <gs...@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?
>
> - 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
Re: Creating a queue and bindings from an address in qpid.messaging
/ AMQP 1.0
Posted by Gordon Sim <gs...@redhat.com>.
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