I am implementing a client/workers system using ActiveMQ and I would like to implement a manual Message Acknowledgement and Message Rejection.
Why reject messages? If a worker has too many tasks coming at it, I want that worker to tell the broker to re-queue the original message.
I know there are ways to auto acknowledge or implement transactions, but I'd rather have something like this:
Messages need to be acknowledged within 5 seconds
If they are not acknowledged, the broker will send the message to a different worker
Works can manually reject a message at any time
How can I implement this (without just resending the message to the broker manually)
UPDATE:
To rephrase the question slightly:
How can I ensure unacknowledged messages are re-added back to the queue (and re-delivery can go back to the same consumer that previously did not acknowledge it even -- say that consumer went offline and then came back)
ActiveMQ web page about queues:
If a consumer receives a message and does not acknowledge it before
closing then the message will be redelivered to another consumer.
That's what you want, right? So you have to turn off the AUTO_ACKNOWLEDGEMENT mode and use another mode: CLIENT_ACKNOWLEDGE or probably more selective the INDIVIDUAL_ACKNOWLEDGE.
Rejecting a message is not (yet) possible, see ActiveMQ-Docu:
There is no JMS 'unacknowledge'.
Related
If I understand JMS correctly, the consumer sends acknowledgement to the broker, and the broker understands that the consumer accepted the message. But how does the producer make sure that broker accepted the message? I don't see any acknowledgements in the API.
Does the method send sync or async?
Acknowledgement is a consumer side concept. Acknowledgement is the way
that a consumer informs the JMS provider that it has successfully
received a message. On the producer side, the only notion of
acknowledgement consists of a successful invocation of either the
topic publishe’s publish method or the queue sender’s send method. If
an acknowledgement is given for a message it indicates that the JMS
provider must not deliver that same message to the consumer in
question again and also the JMS provider can release any resources it
is holding on behalf of the said message (i.e if a JMS queue is
considered after acknowledgement of successful delivery, that message
is removed from the queue). In order to minimize resource consumption,
consumer applications need to acknowledge messages as quickly as
possible after successful delivery.
source: http://wso2.com/library/articles/2013/01/jms-message-delivery-reliability-acknowledgement-patterns/
Iam working on ActiveMQ application where iam using a consumer which uses Session.CLIENT_ACKNOWLEDGE.
Iam sending the messages received from queue in consumer to a webservice.Assume if i don do message.acknowledge() all the messages sent to webservice are back on the queue in enqueued state.
My question is how to retrieve the messages again from the queue and use it.I used retroactive=true and tried redelivery also but all of them are failing.
How to avoid this.
if you use message.acknowledge() all consumed messages are not available again in the same queueu because the are considered as delivered!
can you explain why you need to consume again the messages already consumed.
retroactive is for consumers who was offline and when starting connection to receive messages sent before the connection.
You need to setup the prefetch policy for the consumer to 400 in this case.
You can read to understand the concept http://activemq.apache.org/what-is-the-prefetch-limit-for.html
If you want to treat messages one by one with counter you need to set prefetch to 1 and acknowledge each message when you treat 200 you don't acknowledge.
I am totally new to spring framework. I am trying to create a java maven project where I can have the connectivity to the rabbitMq and I even before publish the message, I want to check if the queues are alive or not. Is this possible to ping the queue to see if it a alive or not.. I am totally new to this rabbitMQ.
Thanks for the answers
Checking for the availability of a queue is a bit of an anti-pattern with messaging systems.
The message producer should not care if there is something on the other end to receive / process the message. The producer only cares that the RabbitMQ instance is available, with the correct exchange.
If the message must be delivered to a consumer, guaranteed, then the consumer needs to configure the queue with durability in mind and the producer should send the message with the persistence flag to ensure it is written to disk.
...
re-reading your question, i'm wondering if you mean "rabbitmq server" when you say "queue". are you wanting to check if the rabbitmq server is available?
if that is the case, the proper thing to do is use a heartbeat in your RabbitMQ connection. the spring framework should know how to do this, and should respond with some kind of event or other code that executes when the connection dies. i'm not really familiar with spring, though, so i don't know the details of doing that with this framework.
You might check this post or this RabbitMQ page on handling this.
We're using a Tibco client implementation of the JMS API. We have a MessageListener with an onMessage() implementation.
Is there a way with the Tibco client to inspect past (received) messages in the queue? (I realise this totally ignores the logical concept of a queue - I wondered if the queue implementation provided this workaround.)
No. Not for "past" messages.
Messages acknowledged by the receiver are removed from the queue - as their "function" is already done.
You could have a Listener configured to persist your messages in some DB or file - but for future messages.
A client uses a QueueBrowser object to look at messages on a queue without removing them.
#hawkeye Its not possible to browse messages from the past... At any point of time , you can browse destinations only for the pending messages.
There is no way for you browse all the received messages as EMS server usually deletes the message once it has delivered ( acknowledged) for the given delivery mode.
One possible way is to a send copy of the messages to another queue (without any receivers) before actually confirming the messages.
Also it depends on your acknowledgement mode and logic involved.
I am using seda queue as dead letter channel endpoint. It works fine if network is down or other application is down.
What will happen if I restart my own system?
Will I loose my messages in dead letter channel endpoint SEDA queue?
The seda endpoint is not a reliable message solution, meaning any messages sent to a seda destination are subject to loss in the event of a failure/restart. If JMS is not an available solution you will need to provide your own persistence logic to provide message recovery.
Additionally, given that seda endpoints are asynchronous, you must ensure that a pattern of message acknowledgement is used post persistence of the DLQ message so your producer to the DLQ will be notified of success or failure to ensure reliability.
This of course when using a DLQ. You could also use a persistence preprocessor that would store messages meant for delivery and only delete them in the case of a failure to deliver them.