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 Thu, 08 Aug 2013 13:19:12 GMT
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 <jakub@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
>

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