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 2011/09/16 15:18:48 UTC
Defining non-exclusive auto-delete queues in JMS API
Hi,
Today, I found a problem with defining an queue using a very specific
address in JMS API. I have a following address:
response/response_routing_key; { create: receiver, link: { name:
'response_queue', durable: false, x-declare: { auto-delete: false,
exclusive: false, arguments : { 'qpid.max_count': 1000,
'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
This address should:
1) Create a non-durable queue named "response_queue", with
qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
queue should not be exclusive and should not be auto-delete
2) Bind the newly created queue to the exchange named "response" using
the key "response_routing_key"
It almost works, except the auto-delete and exclusive options being
ignored. I was trying to find out why are they getting lost and it
seems the values are properly loaded by the AddressHelper class, but
later they are overwritten in AMQSession_0_10.java on line 1342 and
1342:
1342 node.setExclusive(true);
1343 node.setAutoDelete(!node.isDurable());
(http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
I do not fully understand the reason why are they being overwritten -
is this a bug or is this intentional? Unless there is some intention
behind it, I will enter an JIRA ... eventually I can also prepare a
patch removing these lines.
Regards
Jakub
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Fraser,
I'm not sure how many people really understand the addresses :-).
Anyway, thanks for your tip for using the node - the exclusive and
auto-delete flags seem to work nicely there.
It would still be great if someone will be able to tell me whether the
behaviour with the original address is correct or whether it is a bug
...
Thanks & Regards
JAkub
On Fri, Sep 16, 2011 at 16:55, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> That's a pity.
>
> Have you tried using node instead of link. I have to confess that I'm not
> really clear about the use of link and to be honest most of the addresses
> I've used that have actually created queues have specified node. It's
> probably a red herring but might be worth a try unless somebody has a more
> scientific answer.
>
> BTW I thought exclusive false and autodelete false was actually the default
> behaviour the queue that gets created when I do:
>
> test; {create: receiver, node: {x-declare: {arguments: {'qpid.policy_type':
> ring, 'qpid.max_size': 500000000}}, x-bindings: [{exchange: 'amq.match',
> queue: 'test', key: 'data1', arguments: {x-match: all, data-service:
> amqp-delivery, item-owner: fadams}}]}}
>
> lasts until I explicitly delete it and I can connect multiple consumers to
> it
>
> Frase
>
> Jakub Scholz wrote:
>>
>> Hi Fraser,
>>
>> I was actually trying both, but it doesn't seem to be the problem. The
>> exclusive flag seemed to be set correctly to false until it reached
>> the lines mentioned in the initial email.
>>
>> In Python, it seems to work as I expected - when you set the exclusive
>> option to False, it is created as non-exclusive. If you set it to
>> True, it is exclusive.
>>
>> Regards
>> JAkub
>>
>> On Fri, Sep 16, 2011 at 15:45, Fraser Adams
>> <fr...@blueyonder.co.uk> wrote:
>>
>>>
>>> Hmmm do you need to use False (with an upper case F) rather than false?
>>>
>>> I've been using the org.apache.qpid.messaging.Address.AddressParser for a
>>> couple of things and I'm pretty sure that I noticed True and False got
>>> encoded as a Boolean whereas true and false get encoded as a String.
>>> Pretty
>>> irksome, but that just *may* be your problem??
>>>
>>> HTH
>>> Frase
>>>
>>> Jakub Scholz wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> Today, I found a problem with defining an queue using a very specific
>>>> address in JMS API. I have a following address:
>>>>
>>>> response/response_routing_key; { create: receiver, link: { name:
>>>> 'response_queue', durable: false, x-declare: { auto-delete: false,
>>>> exclusive: false, arguments : { 'qpid.max_count': 1000,
>>>> 'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
>>>>
>>>> This address should:
>>>> 1) Create a non-durable queue named "response_queue", with
>>>> qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
>>>> queue should not be exclusive and should not be auto-delete
>>>> 2) Bind the newly created queue to the exchange named "response" using
>>>> the key "response_routing_key"
>>>>
>>>> It almost works, except the auto-delete and exclusive options being
>>>> ignored. I was trying to find out why are they getting lost and it
>>>> seems the values are properly loaded by the AddressHelper class, but
>>>> later they are overwritten in AMQSession_0_10.java on line 1342 and
>>>> 1342:
>>>>
>>>> 1342 node.setExclusive(true);
>>>> 1343 node.setAutoDelete(!node.isDurable());
>>>>
>>>>
>>>> (http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
>>>>
>>>> I do not fully understand the reason why are they being overwritten -
>>>> is this a bug or is this intentional? Unless there is some intention
>>>> behind it, I will enter an JIRA ... eventually I can also prepare a
>>>> patch removing these lines.
>>>>
>>>> Regards
>>>> Jakub
>>>>
>>>> ---------------------------------------------------------------------
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
That's a pity.
Have you tried using node instead of link. I have to confess that I'm
not really clear about the use of link and to be honest most of the
addresses I've used that have actually created queues have specified
node. It's probably a red herring but might be worth a try unless
somebody has a more scientific answer.
BTW I thought exclusive false and autodelete false was actually the
default behaviour the queue that gets created when I do:
test; {create: receiver, node: {x-declare: {arguments:
{'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
[{exchange: 'amq.match', queue: 'test', key: 'data1', arguments:
{x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}
lasts until I explicitly delete it and I can connect multiple consumers
to it
Frase
Jakub Scholz wrote:
> Hi Fraser,
>
> I was actually trying both, but it doesn't seem to be the problem. The
> exclusive flag seemed to be set correctly to false until it reached
> the lines mentioned in the initial email.
>
> In Python, it seems to work as I expected - when you set the exclusive
> option to False, it is created as non-exclusive. If you set it to
> True, it is exclusive.
>
> Regards
> JAkub
>
> On Fri, Sep 16, 2011 at 15:45, Fraser Adams
> <fr...@blueyonder.co.uk> wrote:
>
>> Hmmm do you need to use False (with an upper case F) rather than false?
>>
>> I've been using the org.apache.qpid.messaging.Address.AddressParser for a
>> couple of things and I'm pretty sure that I noticed True and False got
>> encoded as a Boolean whereas true and false get encoded as a String. Pretty
>> irksome, but that just *may* be your problem??
>>
>> HTH
>> Frase
>>
>> Jakub Scholz wrote:
>>
>>> Hi,
>>>
>>> Today, I found a problem with defining an queue using a very specific
>>> address in JMS API. I have a following address:
>>>
>>> response/response_routing_key; { create: receiver, link: { name:
>>> 'response_queue', durable: false, x-declare: { auto-delete: false,
>>> exclusive: false, arguments : { 'qpid.max_count': 1000,
>>> 'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
>>>
>>> This address should:
>>> 1) Create a non-durable queue named "response_queue", with
>>> qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
>>> queue should not be exclusive and should not be auto-delete
>>> 2) Bind the newly created queue to the exchange named "response" using
>>> the key "response_routing_key"
>>>
>>> It almost works, except the auto-delete and exclusive options being
>>> ignored. I was trying to find out why are they getting lost and it
>>> seems the values are properly loaded by the AddressHelper class, but
>>> later they are overwritten in AMQSession_0_10.java on line 1342 and
>>> 1342:
>>>
>>> 1342 node.setExclusive(true);
>>> 1343 node.setAutoDelete(!node.isDurable());
>>>
>>> (http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
>>>
>>> I do not fully understand the reason why are they being overwritten -
>>> is this a bug or is this intentional? Unless there is some intention
>>> behind it, I will enter an JIRA ... eventually I can also prepare a
>>> patch removing these lines.
>>>
>>> Regards
>>> Jakub
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Fraser,
I was actually trying both, but it doesn't seem to be the problem. The
exclusive flag seemed to be set correctly to false until it reached
the lines mentioned in the initial email.
In Python, it seems to work as I expected - when you set the exclusive
option to False, it is created as non-exclusive. If you set it to
True, it is exclusive.
Regards
JAkub
On Fri, Sep 16, 2011 at 15:45, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> Hmmm do you need to use False (with an upper case F) rather than false?
>
> I've been using the org.apache.qpid.messaging.Address.AddressParser for a
> couple of things and I'm pretty sure that I noticed True and False got
> encoded as a Boolean whereas true and false get encoded as a String. Pretty
> irksome, but that just *may* be your problem??
>
> HTH
> Frase
>
> Jakub Scholz wrote:
>>
>> Hi,
>>
>> Today, I found a problem with defining an queue using a very specific
>> address in JMS API. I have a following address:
>>
>> response/response_routing_key; { create: receiver, link: { name:
>> 'response_queue', durable: false, x-declare: { auto-delete: false,
>> exclusive: false, arguments : { 'qpid.max_count': 1000,
>> 'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
>>
>> This address should:
>> 1) Create a non-durable queue named "response_queue", with
>> qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
>> queue should not be exclusive and should not be auto-delete
>> 2) Bind the newly created queue to the exchange named "response" using
>> the key "response_routing_key"
>>
>> It almost works, except the auto-delete and exclusive options being
>> ignored. I was trying to find out why are they getting lost and it
>> seems the values are properly loaded by the AddressHelper class, but
>> later they are overwritten in AMQSession_0_10.java on line 1342 and
>> 1342:
>>
>> 1342 node.setExclusive(true);
>> 1343 node.setAutoDelete(!node.isDurable());
>>
>> (http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
>>
>> I do not fully understand the reason why are they being overwritten -
>> is this a bug or is this intentional? Unless there is some intention
>> behind it, I will enter an JIRA ... eventually I can also prepare a
>> patch removing these lines.
>>
>> Regards
>> Jakub
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hmmm do you need to use False (with an upper case F) rather than false?
I've been using the org.apache.qpid.messaging.Address.AddressParser for
a couple of things and I'm pretty sure that I noticed True and False got
encoded as a Boolean whereas true and false get encoded as a String.
Pretty irksome, but that just *may* be your problem??
HTH
Frase
Jakub Scholz wrote:
> Hi,
>
> Today, I found a problem with defining an queue using a very specific
> address in JMS API. I have a following address:
>
> response/response_routing_key; { create: receiver, link: { name:
> 'response_queue', durable: false, x-declare: { auto-delete: false,
> exclusive: false, arguments : { 'qpid.max_count': 1000,
> 'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
>
> This address should:
> 1) Create a non-durable queue named "response_queue", with
> qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
> queue should not be exclusive and should not be auto-delete
> 2) Bind the newly created queue to the exchange named "response" using
> the key "response_routing_key"
>
> It almost works, except the auto-delete and exclusive options being
> ignored. I was trying to find out why are they getting lost and it
> seems the values are properly loaded by the AddressHelper class, but
> later they are overwritten in AMQSession_0_10.java on line 1342 and
> 1342:
>
> 1342 node.setExclusive(true);
> 1343 node.setAutoDelete(!node.isDurable());
> (http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
>
> I do not fully understand the reason why are they being overwritten -
> is this a bug or is this intentional? Unless there is some intention
> behind it, I will enter an JIRA ... eventually I can also prepare a
> patch removing these lines.
>
> Regards
> Jakub
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Gordon Sim <gs...@redhat.com>.
On 09/19/2011 07:04 PM, Jakub Scholz wrote:
> OK, JIRA QPID-3494 entered. In your opinion, should the lines of code
> overwriting the exclusive and auto-delete options be removed or
> replaced by different behaviour?
I'll defer to Rajith (who I know to have some improvements in this area
under way) and/or others on that. Thanks again for raising the Jira.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Sep 19, 2011 at 2:04 PM, Jakub Scholz <ja...@scholz.cz> wrote:
> OK, JIRA QPID-3494 entered. In your opinion, should the lines of code
> overwriting the exclusive and auto-delete options be removed or
> replaced by different behaviour?
>
> I can try to prepare a patch ... although preparing a patch for
> deleting two lines may be little bit excesive :-)
Jakub, sorry for the late reply. Catching up with the user list now :)
First of all thanks for raising this JIRA.
I have done some work on the addressing code to address a few issues,
including the one you raised.
The code you refer to will no not be there once the patch is applied.
The time frame for this fix is the upcoming 0.14 release.
> Regards
> Jakub
>
> On Mon, Sep 19, 2011 at 19:31, Gordon Sim <gs...@redhat.com> wrote:
>> On 09/19/2011 06:16 PM, Jakub Scholz wrote:
>>>
>>> The use case ... is complicated :-). We use the temporary queues in
>>> request-response pattern for responses. We wanted to allow the clients
>>> to connect with several applications using one account and still use
>>> easily the request-response pattern ... i.e. without using the same
>>> queue from multiple applications. If we preconfigure the queues, we
>>> will not know how many queues to create for each client account. That
>>> worked fine, because if you want one queue per application, you don't
>>> mind the exclusivity. However last week we got into a problem, because
>>> one of our 3rd party servers isn't supporting a proper use of the
>>> ReplyTo property when responding to requests. Instead, it is able to
>>> send the answer only to one specific destination. Till it is fixed in
>>> the 3rd party server, we tried to share one queue between applications
>>> and that's how we found the problem. I hope this use case description
>>> is understandable ... :-o
>>
>> Yes it does, thanks for taking the time to explain!
>>>
>>> I'm not sure about the shorthands ... I personally would prefer more
>>> complex description which really does what I want instead of having
>>> some shortcuts.
>>
>> Yes, I understand. The current syntax is intended to give more or less
>> complete control over the AMQP 0-10 mapping.
>>
>> Shorthands was probably also the wrong word. What I mean is that the
>> addressing is intended to be a protocol neutral way of declaratively
>> describing message sources and targets. Where complex address strings are
>> needed, we likely want to abstract the core purpose so that it can be
>> expressed more simply and mapped automatically to the correct protocol
>> version.
>>
>>> I was also thinking about compiling some "example"
>>> addresses for the most used situations
>>>
>>> Since the attributes are supported in Python and according to you also
>>> in C++, I will enter an JIRA to get this fixed also in Java ...
>>
>> Marvellous, thank you!
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
OK, JIRA QPID-3494 entered. In your opinion, should the lines of code
overwriting the exclusive and auto-delete options be removed or
replaced by different behaviour?
I can try to prepare a patch ... although preparing a patch for
deleting two lines may be little bit excesive :-)
Regards
Jakub
On Mon, Sep 19, 2011 at 19:31, Gordon Sim <gs...@redhat.com> wrote:
> On 09/19/2011 06:16 PM, Jakub Scholz wrote:
>>
>> The use case ... is complicated :-). We use the temporary queues in
>> request-response pattern for responses. We wanted to allow the clients
>> to connect with several applications using one account and still use
>> easily the request-response pattern ... i.e. without using the same
>> queue from multiple applications. If we preconfigure the queues, we
>> will not know how many queues to create for each client account. That
>> worked fine, because if you want one queue per application, you don't
>> mind the exclusivity. However last week we got into a problem, because
>> one of our 3rd party servers isn't supporting a proper use of the
>> ReplyTo property when responding to requests. Instead, it is able to
>> send the answer only to one specific destination. Till it is fixed in
>> the 3rd party server, we tried to share one queue between applications
>> and that's how we found the problem. I hope this use case description
>> is understandable ... :-o
>
> Yes it does, thanks for taking the time to explain!
>>
>> I'm not sure about the shorthands ... I personally would prefer more
>> complex description which really does what I want instead of having
>> some shortcuts.
>
> Yes, I understand. The current syntax is intended to give more or less
> complete control over the AMQP 0-10 mapping.
>
> Shorthands was probably also the wrong word. What I mean is that the
> addressing is intended to be a protocol neutral way of declaratively
> describing message sources and targets. Where complex address strings are
> needed, we likely want to abstract the core purpose so that it can be
> expressed more simply and mapped automatically to the correct protocol
> version.
>
>> I was also thinking about compiling some "example"
>> addresses for the most used situations
>>
>> Since the attributes are supported in Python and according to you also
>> in C++, I will enter an JIRA to get this fixed also in Java ...
>
> Marvellous, thank you!
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Gordon Sim <gs...@redhat.com>.
On 09/19/2011 06:16 PM, Jakub Scholz wrote:
> The use case ... is complicated :-). We use the temporary queues in
> request-response pattern for responses. We wanted to allow the clients
> to connect with several applications using one account and still use
> easily the request-response pattern ... i.e. without using the same
> queue from multiple applications. If we preconfigure the queues, we
> will not know how many queues to create for each client account. That
> worked fine, because if you want one queue per application, you don't
> mind the exclusivity. However last week we got into a problem, because
> one of our 3rd party servers isn't supporting a proper use of the
> ReplyTo property when responding to requests. Instead, it is able to
> send the answer only to one specific destination. Till it is fixed in
> the 3rd party server, we tried to share one queue between applications
> and that's how we found the problem. I hope this use case description
> is understandable ... :-o
Yes it does, thanks for taking the time to explain!
>
> I'm not sure about the shorthands ... I personally would prefer more
> complex description which really does what I want instead of having
> some shortcuts.
Yes, I understand. The current syntax is intended to give more or less
complete control over the AMQP 0-10 mapping.
Shorthands was probably also the wrong word. What I mean is that the
addressing is intended to be a protocol neutral way of declaratively
describing message sources and targets. Where complex address strings
are needed, we likely want to abstract the core purpose so that it can
be expressed more simply and mapped automatically to the correct
protocol version.
> I was also thinking about compiling some "example"
> addresses for the most used situations
>
> Since the attributes are supported in Python and according to you also
> in C++, I will enter an JIRA to get this fixed also in Java ...
Marvellous, thank you!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Gordon,
At the end I needed to use an address like this:
response_queue; {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: 'response', queue:
'response_queue', key: 'response_routing_key'}]}}
I.e., I used the "create: receiver", but I specified the node type to
be queue. (The exchange response exists - it is predefined by us) I
agree that this address describes better what I'm doing. I iterated to
the original address during some time (I got some initial help here on
the mailing list). It works nicely unless you want non-exclusive
and/or non-autodelete queues.
The use case ... is complicated :-). We use the temporary queues in
request-response pattern for responses. We wanted to allow the clients
to connect with several applications using one account and still use
easily the request-response pattern ... i.e. without using the same
queue from multiple applications. If we preconfigure the queues, we
will not know how many queues to create for each client account. That
worked fine, because if you want one queue per application, you don't
mind the exclusivity. However last week we got into a problem, because
one of our 3rd party servers isn't supporting a proper use of the
ReplyTo property when responding to requests. Instead, it is able to
send the answer only to one specific destination. Till it is fixed in
the 3rd party server, we tried to share one queue between applications
and that's how we found the problem. I hope this use case description
is understandable ... :-o
I'm not sure about the shorthands ... I personally would prefer more
complex description which really does what I want instead of having
some shortcuts. I was also thinking about compiling some "example"
addresses for the most used situations
Since the attributes are supported in Python and according to you also
in C++, I will enter an JIRA to get this fixed also in Java ...
Thanks & Regards
Jakub
On Mon, Sep 19, 2011 at 17:35, Gordon Sim <gs...@redhat.com> wrote:
> On 09/16/2011 02:18 PM, Jakub Scholz wrote:
>>
>> Hi,
>>
>> Today, I found a problem with defining an queue using a very specific
>> address in JMS API. I have a following address:
>>
>> response/response_routing_key; { create: receiver, link: { name:
>> 'response_queue', durable: false, x-declare: { auto-delete: false,
>> exclusive: false, arguments : { 'qpid.max_count': 1000,
>> 'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
>>
>> This address should:
>> 1) Create a non-durable queue named "response_queue", with
>> qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
>> queue should not be exclusive and should not be auto-delete
>> 2) Bind the newly created queue to the exchange named "response" using
>> the key "response_routing_key"
>
> An alternative address to accomplish that would be:
>
> response_queue; {create: receiver, node: {x-declare:{arguments : {
> 'qpid.max_count': 1000, 'qpid.max_size': 1000000, 'qpid.policy_type': ring
> }}, x-bindings:['exchange':'response',key:'response_routing_key']}}
>
> To my mind that is a more 'natural' expression of what you want. I.e. a
> queue created on first use that is bound in a particular fashion.
>
> [Note that the 'create: receiver' is almost certainly not what you want
> here. With no node type specified, that would result in a queue named
> response being created if no other node of that name existed.]
>
>> It almost works, except the auto-delete and exclusive options being
>> ignored. I was trying to find out why are they getting lost and it
>> seems the values are properly loaded by the AddressHelper class, but
>> later they are overwritten in AMQSession_0_10.java on line 1342 and
>> 1342:
>>
>> 1342 node.setExclusive(true);
>> 1343 node.setAutoDelete(!node.isDurable());
>>
>> (http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
>>
>> I do not fully understand the reason why are they being overwritten -
>> is this a bug or is this intentional? Unless there is some intention
>> behind it, I will enter an JIRA ... eventually I can also prepare a
>> patch removing these lines.
>
> I can only speculate, but FWIW...
>
> The C++ client also originally ignored any setting of the exclusive flag on
> subscription queues. For the use cases anticipated at the time it seemed
> that you would always want a subscription queue to be used by only one
> subscriber. Alternative uses seemed to be better served by configuration
> independent of addressing (or perhaps by the above).
>
> However I then decided that this was a bug - for the sake of consistency if
> nothing else - and the exclusive setting within an x-declare should now be
> honoured even for a link.
>
> I would be interested in the use case here. Why for example is this address
> preferable to pre-configuring the broker, including creating necessary
> queues and bindings, before the application(s) start to use it? Getting a
> better understanding of the use cases people care about will help evolve the
> addressing syntax to support simpler shorthands.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Defining non-exclusive auto-delete queues in JMS API
Posted by Gordon Sim <gs...@redhat.com>.
On 09/16/2011 02:18 PM, Jakub Scholz wrote:
> Hi,
>
> Today, I found a problem with defining an queue using a very specific
> address in JMS API. I have a following address:
>
> response/response_routing_key; { create: receiver, link: { name:
> 'response_queue', durable: false, x-declare: { auto-delete: false,
> exclusive: false, arguments : { 'qpid.max_count': 1000,
> 'qpid.max_size': 1000000, 'qpid.policy_type': ring } } } }
>
> This address should:
> 1) Create a non-durable queue named "response_queue", with
> qpid.max_count=1000, qpid.max_size=1000000, qpid.policy_type=ring. The
> queue should not be exclusive and should not be auto-delete
> 2) Bind the newly created queue to the exchange named "response" using
> the key "response_routing_key"
An alternative address to accomplish that would be:
response_queue; {create: receiver, node: {x-declare:{arguments : {
'qpid.max_count': 1000, 'qpid.max_size': 1000000, 'qpid.policy_type':
ring }}, x-bindings:['exchange':'response',key:'response_routing_key']}}
To my mind that is a more 'natural' expression of what you want. I.e. a
queue created on first use that is bound in a particular fashion.
[Note that the 'create: receiver' is almost certainly not what you want
here. With no node type specified, that would result in a queue named
response being created if no other node of that name existed.]
> It almost works, except the auto-delete and exclusive options being
> ignored. I was trying to find out why are they getting lost and it
> seems the values are properly loaded by the AddressHelper class, but
> later they are overwritten in AMQSession_0_10.java on line 1342 and
> 1342:
>
> 1342 node.setExclusive(true);
> 1343 node.setAutoDelete(!node.isDurable());
> (http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?view=markup)
>
> I do not fully understand the reason why are they being overwritten -
> is this a bug or is this intentional? Unless there is some intention
> behind it, I will enter an JIRA ... eventually I can also prepare a
> patch removing these lines.
I can only speculate, but FWIW...
The C++ client also originally ignored any setting of the exclusive flag
on subscription queues. For the use cases anticipated at the time it
seemed that you would always want a subscription queue to be used by
only one subscriber. Alternative uses seemed to be better served by
configuration independent of addressing (or perhaps by the above).
However I then decided that this was a bug - for the sake of consistency
if nothing else - and the exclusive setting within an x-declare should
now be honoured even for a link.
I would be interested in the use case here. Why for example is this
address preferable to pre-configuring the broker, including creating
necessary queues and bindings, before the application(s) start to use
it? Getting a better understanding of the use cases people care about
will help evolve the addressing syntax to support simpler shorthands.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org