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:[email protected]
