hum. regarding the auto-delete, looks like this is my fault.
I changed my JMS code to explicitly use a temp queue
TemporaryQueue tmpQueue = session.createTemporaryQueue();
messageConsumer = session.createConsumer(tmpQueue, "msg selector....")
and then the queues are created as auto delete
temp_rcv_qpid-jms:temp-queue-creator:ID::48e3b12c-a7f8-42cf-b499-168ddda7546a:1:1
auto-del
do not need to use the QueuePolicy
On Tue, Dec 22, 2015 at 10:50 AM, Olivier Mallassi <
olivier.malla...@gmail.com> wrote:
> - I am using session.createConsumer(myTopic, "messageSelector") so AFAIK,
> it is not durable subscription. I was also reading
> http://qpid.2158936.n2.nabble.com/Autodelete-queues-not-deleted-td7633221.html
> and the QueuePolicy. Not sure how it maps to the jms destination name
> (maybe the jms.queueprefix) but maybe that can help
>
> - indeed JMS 2.0 defined shared subscription. Anyway, maybe during that
> time I need to rely on AMQP 0.10 bindings (within the broker) to have
> queues on which consumers can compete.
>
>
>
> On Tue, Dec 22, 2015 at 10:39 AM, Gordon Sim <g...@redhat.com> wrote:
>
>> On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
>>
>>> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
>>> creates a queue with an uniqueID for each receiver (e.g.
>>>
>>> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
>>>
>>
>> Actually that queue is created on the broker side. The name comes from
>> the container id and link name.
>>
>> - is there a way to auto-delete this "queue" when the consumer JVM shut
>>> down?
>>>
>>
>> It should be auto-deleted by default, unless the client requests
>> otherwise. Is it a durable subscription on the topic that you created?
>>
>> - is there a way to share this "queue" between multiple consumers so that
>>> they can compete each other?
>>>
>>
>> At the AMQP protocol level, all receiving links that request a 'shared'
>> capability on the link and use the same link name (from the same topic
>> obviously) will share the subscription (i.e. the messages from that
>> subscription will be distributed between them). (This is not a standard
>> capability).
>>
>> I'm not sure if the JMS client will allow you to set the capabilities
>> though (Robbie?). At some point the JMS client will support JMS 2.0 which
>> includes the notion of shared subscriptions and as part of that a standard
>> approach at the protocol level will hopefully emerge.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
