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/
Related
I have a queue with one producer and two consumers using CLIENT_ACKNOWLEDGE. The two consumers share the connections, but they live in different threads so each uses its own session.
What happens if consumer A does not acknowledge the last message received? In which scenario the message will be re-delivered and consumed by consumer B? Is it when the session consumer A is using is closed? Do I need some configuration on JMS provider to dictate what happens in such a scenario?
I don't think this situation is directly addressed in the JMS specification so the answer will ultimately depend on what JMS broker you're using. However, having worked on multiple JMS brokers in the past I would say that generally speaking any message that has been dispatched by the broker to a consumer but which hasn't yet been acknowledged by that consumer will be cancelled back to the broker and will be made available for redelivery once the consumer in question is closed.
We have a producer service which is publishing a message to topic and we have 3 instances of consumers reading that message from topic. Producer needs to do further processing (update DB) only when all consumers processed and replied a success message in another reply queue. Even if one of the consumer service failed due to some exception or any failure message in reply queue, producer should not do update DB for that publish request.
For next request (new message published in topic), if all consumers processed and replied in reply queue, producer should update DB. How can we achieve this with camel and activemq. Is there any EIP pattern(s) to achieve this?
Any
Yes, the producer can just use the aggregator enterprise integration pattern on the reply queue to ensure all 3 consumers processed the previous message.
Doc: Apache Camel aggregator2 component.
You will need a unique key and use a proper aggregation strategy.
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'.
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.