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 <[email protected]> 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:[email protected]
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
