On 11/20/2012 03:20 PM, eugene wrote:
Hello,
So here is my pretty much simple scenario. I want to take advantage of the
orphaned messages and the alternate exchange. From what I read, if a message
ends up in a queue and that queue get's deleted (but it has an alternate
exchange declared), the queue will indeed get deleted, but the messages
present in it will get re-directed to the alternate exchange. 1) Right?
Right.
2) The scenario I have is pretty much complicated, but put is simple is
this:
A producer flow:
private static final String ALTERNATE_EXCHANGE = "amq.topic";
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
Queue testQueue = session.createQueue("TEST_QUEUE;
{create:always,
node:{x-declare:{auto-delete:true, exclusive: true, alternate-exchange:
'"+ALTERNATE_EXCHANGE+"'}}}");
System.out.println("Will send message to : " +
testQueue.toString());
MessageProducer producer = session.createProducer(testQueue);
TextMessage message = session.createTextMessage("Some
value");
producer.send(message);
Notice the auto-delete true, if producer.send(message) is the last line of
my code - and indeed it is, then immediately after it, the queue TEST_QUEUE
will be deleted and the message routed to the amq.topic exchange. If only I
had a listener on that exchange...
Depending on your configuration the send() call may be asynchronous. I
don't know what the JMS client does if you have no explicit cleanup. One
thing I would check is that the message is actually getting to the broker.
Turning on the broker logging would help there. If you are using qpidd,
then just add --log-enable trace+:amqp_0_10 --log-enable notice+ (or
similar). You can send in the output for that and we can make sure that
the queue is created as expected and the message is enqueued on it.
And I do have one:
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
Thread thread = new Thread(new MyRunnable(session));
thread.start();
}
private static final class MyRunnable implements Runnable {
private final Session session;
public MyRunnable(Session session){
this.session = session;
}
public void run(){
try {
MessageConsumer consumer =
session.createConsumer(session.createQueue("amq.topic"));
This may have no affect, but createTopic() would probably be more
accurate there. (You don't want a queue called amq.topic after all).
The other question is how the JMS client handles that address.
Specifically does it create a binding that matches all messages (i.e.
'#'). If you don't need to filter, perhaps using amq.fanout would be
simpler.
consumer.setMessageListener(new
MyMessageListener());
//Should be a flag here, but ignore for now
while(true){}
} catch (JMSException e) {
e.printStackTrace();
}
}
}
private static final class MyMessageListener implements MessageListener
{
public void onMessage(Message message){
System.out.println("Message Received");
if(message instanceof TextMessage) {
try {
System.out.println("Payload : " +
((TextMessage)message).getText());
} catch (JMSException e) {
e.printStackTrace();
}
}
}
}
But not a single message hits my listener. :(
So does this sound like a bug or something stupid that I did not get right?
It's certainly not something stupid... it may well be some behaviour on
the JMS client that is not immediately obvious. If you can get a broker
log as described above for this brief sequence that would help a lot.
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
