I have recently started using ActiveMQ 5.8. I have the default activemq.xml setup and am doing some simple testing with the ActiveMQ web admin. When I send a message to a queue through the ui, the queue will show a pending message for about 5 seconds, then the message will get dequeued. There are no consumers set up on this queue. Why is the message not staying in the queue? In older versions of ActiveMQ, doing this same procedure, the message will remain in the queue, as expected. Did something change with 5.8?
This happened to me recently. Check activemq.xml for
<plugins>
<timeStampingBrokerPlugin zeroExpirationOverride="1000" ttlCeiling="60000" futureOnly="true"/>
</plugins>
zeroExpirationOverride="1000" would automatically expire any message after one second without any consumer being attached.
Related
After the rabbitmq server or cluster is restarted, all the queue have recover all the message even the messages have be acked (from the point that rabbitmq server is started), and process all messages again.
Queue details
From my understanding, setting persistenet to false in the message arguments, the message will not survive if broker restart. Also, I have set durabele to false for the queue.
Did I missed any other settings?
Making a message persistent true is fine as you do not want to loose message in case of rabbitmq restart. Secondly, it is also fine to make the queue durable so that you dont want to loose the queue in case of rabbitmq restart. I will suggest please check the message consumer code as it looks like it is not commiting the transaction on its side making the message available on the queue. What you can do is after consuming messages please stop the consumer and check on the RabbitMQ if the messages are still available on the queue. If the messages are still available on queue after stopping the consumer , then there must be some issue on the consumer code.
We have observed the following behavior of RabbitMQ and are trying to understand if it is correct and how to resolve it.
Scenario:
A (persistent) message is delivered into a durable queue
The (single) Consumer (Spring-AMQP) takes the message and starts processing => Message goes from READY to UNACK
Now the broker is shut down => Client correctly reports "Channel shutdown"
The consumer finishes the processing, but can not acknowledge the message as the broker is still down
Broker is started again => Client reconnects
As a result, one message remains unack'ed forever (or until the client is restarted).
Side note: In the Rabbit Admin UI, I can see that two channels are existing now. The "dead" one that was created before the broker restart, containing the unacked message and a new one that is healthy.
Is this behavior expected to be like that? It seems to me "correct" in the way, that RabbitMQ can not know after the broker restart, whether the message processing was completed or not. But what solution would exist than to get that unacked message back into the queue and to heal the system without restarting the consumer process?
The RabbitMQ team monitors this mailing list and only sometimes answers questions on StackOverflow.
Is this behavior expected to be like that? It seems to me "correct" in the way, that RabbitMQ can not know after the broker restart, whether the message processing was completed or not.
Yes, you are observing expected behavior. RabbitMQ will re-enqueue the message once it determines that the consumer is really dead. Since your consumer re-connects with what must be the same consumer tag as before, it is up to that process to ack or nack the message.
I have a 3 node cluster of Rabbitmq behind a HAproxy Load Balancer. When I shut down a node, Rabbitmq successfully switches the queue to the other nodes. However, I notice that Logstash stops pulling messages from the queue unless I restart it. Is this a problem with the way rabbitmq operates? i.e. it deactivates all active consumers. I am not sure if log stash has any retry capability. Anyone run into this issue?
Quoting rabbit mq documentation, page for clustering first
What is Replicated? All data/state required for the operation of a
RabbitMQ broker is replicated across all nodes. An exception to this
are message queues, which by default reside on one node, though they
are visible and reachable from all nodes.
and high availability
Clients that are consuming from a mirrored queue may wish to know that
the queue from which they have been consuming has failed over. When a
mirrored queue fails over, knowledge of which messages have been sent
to which consumer is lost, and therefore all unacknowledged messages
are redelivered with the redelivered flag set. Consumers may wish to
know this is going to happen.
If so, they can consume with the argument x-cancel-on-ha-failover set
to true. Their consuming will then be cancelled on failover and a
consumer cancellation notification sent. It is then the consumer's
responsibility to reissue basic.consume to start consuming again.
So, what does all this mean:
You have to mirror queues
The consumers should use manual ACK
The consumers should reconnect on their own
So the answer to your question is no, it's not a problem with rabbitmq, that's simply how it works. It's up to clients to reconnect.
My application consumes JMS messages in a Glassfish 3.1.2 server and OpenMQ as JMS provider.
The strange behavior happens when a consumer fails to process a message. In this situation Glassfish correctly move the message to the Dead Message Queue (after 2 attempts). And this is fine.
When I restart the server, the message stored in the DMQ, is sent again to the original destination (and that's ok, althoug I didn't expect this behavior). Now, also if the consumer succeed, the message remains in the destination.
That's incorrect because, after another restart of the server, the message is consumed again. Strangely this time the message is permanently removed from the queue.
The questions are:
why the message remains in the queue?
And why GF try to move automatically the message from the DMQ into the original one, after a restart?
I use ActiveMQ as a job dispatcher. Which means one master sends job messages to ActiveMQ, and multiple slaves grab job messages from ActiveMQ and process them. When slaves finish one job, they send a message with job_id back to ActiveMQ.
However, slaves are unreliable. If one slave doesn't respond before a period of time, we can assume the slave is down, and try redeliver the sent job message.
Are there any good ideas to realize this re-delivery?
Typically a consumer handles redelivery so that it can maintain message order while a message appears as inflight on the broker. This means that redelivery is limited to a single consumer unless that consumer terminates. In this way the broker is unaware of redelivery.
In ActiveMQ v5.7+ you have the option of using broker side redelivery, it is possible to have the broker redeliver a message after a delay using a resend. This is implemented by a broker plugin that handles dead letter processing by redelivery via the scheduler. This is useful when total message order is not important and where through put and load distribution among consumers is. With broker redelivery, messages that fail delivery to a given consumer can get immediately re-dispatched.
See the ActiveMQ documentation for an example of setting this up in the configuration file.