I am using spring cloud stream with rabbitMQ.
I am trying to do the negative test by deleting the queue on runtime and post the message to the deleted queue.
source.queue2Source().send(MessageBuilder.withPayload(queue4DTO).build());
I am listening message from queue 1 and posting the message to queue 2( deleted one). I was expecting that above code will throw an exception but it is not. Even the message from reading from queue 1 has been acknowledged. I have a dead letter queue on queue 1 and queue 2 but message not went into dlq.
That is because the you are sending message to a channel defined by the Source. The channel actually does exist and is bridged via AMQPOutboundChannelAdapter to an exchange which by default will drop undeliverable messages.
Related
Question one: Can I subscribe to the event of a message being sent to the _skipped queue?
I am using masstransit together with rabbit mq. Some messages sometimes are sent to the _skipped queue for unclear reasons. The message type has a consumer, the ttl (time to life) is not small. It should not happen, and I am getting a log entry from masstransit, but I want to do more at the moment. Maybe log an error, in test maybe pop-up a window. Is there a way to achieve this? I am only getting these log messages below.
MassTransit.ReceiveTransport|SKIP rabbitmq://localhost/services_admin db270000-1fd6-00ff-3b83-08d9000ef97c
MassTransit.ReceiveTransport|Declare queue: name: services_admin_skipped, durable, consumer-count: 0 message-count: 3
Question two: What exactly happens to messages in the _skipped queue? Can they be resent?
Skipped messages either don't match the type (namespace included), don't have a consumer on the endpoint, or were a response to a request client that is no longer waiting for it. Since it's a receive endpoint queue, it's likely one of the first two reasons. Look at the message body/details in the RabbitMQ Management Console, that should give you some ideas.
You can use a shovel in RabbitMQ to move the messages back into the queue once you've resolved the issue.
when we are adding vm listener in our flow with particular queue name, does that means the message is being consumed already? if anything in the listener flow goes wrong, will that message be still there if we have added the queue as persistent?
The message is consumed from the queue by the listener. If the flow is started, the message has been already consumed.
Persistent is related to where the queue is stored before the message is consumed. As I said, if the message is in the flow, it is already removed from the queue. The exception is if you use transactions. Then the message will be consumed when the transaction ends, or not consumed if there is an error.
I am using java client of
https://www.rabbitmq.com/tutorials/tutorial-six-java.html
. My setup is RPC. My server is creating queue and client is also creating same queue and sending the message. After receiving message server is performing some operation and sending result back to client.
Now if server created the queue and connect with it while queue get's deleted for some reason. The server is not throwing any exception and when the client is creating the same queue and putting messages server is not getting those messages either as it's not connected.
How do server knows that the queue get deleted?
Thanks so much
It sounds like the following situation is happening:
Queue A is created.
Consumer 1 subscribes to Queue A
Queue A is deleted while Consumer 1 is still active
Queue A is re-created (call it A')
Now, you're wondering why Consumer 1 is not getting any messages? You would have to re-subscribe your consumer. I don't usually delete queues, because there is no need to do so under any reasonable scenario (instead, use the queue.expires property to handle auto-deletion of queues).
According to the AMQP 0-9-1 Specification,
When a queue is deleted any pending messages are sent to a dead-letter
queue if this is defined in the server configuration, and all
consumers on the queue are cancelled.
So, based on the description of the behavior, this is a bug with the consumer. It should throw an exception or otherwise exit the consuming loop in this case. In any case, you'll have to re-subscribe to A' before you'll get any more messages.
i am using Spring JmsTemplate for sending/pushing message to ActiveMQ queue.
i know after listener start processing that message and any exception occur,that message will be considered as a poison pill and moved to default DLQ of acive mq.
is that same possible (i.e. that message will move to default Dead Letter Queue ) while sending/pushing that message to Queue if there is any connection error or any other error occured while sending?
for example -
public void push(){
jmsTemplate.send(test.Queue, "This message is from client");
//if any exception occur here,i want this message to be placed
in DLQ
}
please suggest is it possible?
If you can't connect to send it the main queue, you probably can't connect to send it to the DLQ either.
Right now I'm working with a JMS queue that has a redelivery policy such that messages that are rolled back more than five times are sent to a dead letter queue.
When a message is sent to a Dead Letter Queue in ActiveMQ, is there a way to see what exception caused that message rollback? Is there a message property I can set to specify what caused the message failure?
If you use the dead letter channel functionality
http://activemq.apache.org/message-redelivery-and-dlq-handling.html
of the AMQ broker then its as answered above, literally just the message that couldn't be delivered. The broker does not have any knowledge what went wrong, it just gets a 'rollback' signal on the message.
If you use Camel's dead letter channel functionality
http://camel.apache.org/dead-letter-channel.html
then Camel stores the caused exception as a property on the Exchange, which you can enrich on the failed message, and send it to a dead letter queue, in the AMQ broker. So instead of letting AMQ rollback the message, you handle the exception, and send the message to another queue, which happens to be a dead letter queue. You can then enrich the message by taking the stacktrace and/or exception message from the Exchange property and store somewhere on the message, in a header etc.
Camel stores the caught exception as a property on the Exchange with the key: Exchange.EXCEPTION_CAUGHT
You'll need to look in the logs on the box that's generating the exception. What's sent to the DLQ is literally just the message that couldn't be delivered.