On 03/14/2012 10:31 AM, eugene wrote:
I have tried a simple scenario where I have something like this:
1. Create a queue and one fanout exchange - bind them.
2. Create a queue like this: "myQueue; {create:receiver, delete:receiver,
assert:always, node:{x-declare:{auto-delete:true, exclusive: true,
alt-exchange: FANOUT_EXCHANGE}}}" //alternate-exchange does not work either
alternate-exchange is the correct key name and that works for me with
the latest JMS client (by works I mean simply that the queue thus
created has the desired exchange set)
3. Send the message to myQueue, there I have a Listener configured, as soon
as I hit the onMessage, wait forever (while(true){} for example) without
acknowledging the message, thus the message is still inside myQueue.
So does your session have CLIENT_ACKNOWLEDGE mode set, or you are just
delaying acknowledgement by never returning from the onMessage()?
Check the queue size with qpid-tool, show<ID> : myQueue has one message
which I expect to happen, because I did not do message. acknowledge() so
far.
Stop the running Thread at all - the application if you want. the queue will
be deleted because of the declaration of it, thus the message inside it will
be orphaned, thus, from my understanding it will be sent to the
alternate-exchange, which does not happen.
The queue be deleted either when the session that declared it closes
(due to the auto-delete and exclusive combination) or when the
MessageConsumer is closed (due to the delete:receiver).
Is there anything that I am missing or may be this is a known-issue?
Has the queue actually been deleted? If you run qpid-stat -q for
example, does it show up?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
