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.
Related
By using only one JMS Queue, is it possible for an application to consume and produce on it ?
Or it needs to use two JMS Queue ? One for consuming and other for producing.
Thanks you in advance.
Yes it is perfectly valid to have one application to produce and consume messages from the same Q.
Be careful with the transaction demarcation, ie "commit" the transaction after sending the message in order for the message to be "visible" to the consumer, including the consumer in your your application
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/
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'.
During configuration of JMS queues on JBoss 7 with HornetQ (based on standalone-full.xml configuration) I noticed an attribute 'durable'.
I browsed several sources and many of them stated queues are always 'durable', meaning the message will be always delivered, even in case of potential receivers being inactive at the time of send.
Does this attribute in JBoss 7 HornetQ refer to temporary queues? Or does this attribute refer to some kind of non-temporary non-durable queues?
I feel the word "Durable" is more applicable to Topics than queues. A durable subscription is one where the publications for a subscriber are stored by the messaging provider when that subscriber is not running. Once the subscriber becomes active, these stored messages will be delivered to that subscriber. For non-Durable subscribers will not receive any publications if they are not active.
With respect to Queues, the messages are held in the queue till someone receives them or they expire. The messages can be persistent meaning they will survive restart of messaging provider and non-persistent where the messages are lost when messaging provider goes down.
After brief investigation I came up with a few conclusions. All observations are based on JBoss 7.1.1.Final with HornetQ Server 2.2.13.Final.
The non-durable queue is not a temporary queue. It exists until it's manually deleted.
All the messages submitted to non-durable queue vanish upon JMS provider restart/failure (delivery modes, i.e. PERSISTENT / NON_PERSISTENT of the submitted messages are ignored).
The value of JMSDeliveryMode header element of the messages is not modified. In particular, if the message was submitted with PERSISTENT delivery mode to a non-durable queue, the flag is set to PERSISTENT, even though the non-durable queue does not persist the message (it is lost in case of JMS provider restart/failure).
From the client side it seems to be a bit of a disturbing prospect, since the sender has potentially no way of knowing whether the declared delivery mode of the message will not be respected, due to the problematic meaning of 'non-durable' queue.
Furthermore, the term 'durable queue' in this context seems disjointed from the 'durable subscription', as it does not appear to affect delivery of messages to inactive consumers in any way.
Durable subscription in JMS means that if subscriber disconnected and then connected again to JMS destination (queue or topic) it will receive all messages that have been sent to the destination so far and have not been expired yet.
I have a JMS topic on an ActiveMQ network of brokers cluster (aka distributed topic). I have an external JMS consumer (Weblogic portal) that needs to subscribe to this topic and get all the messages sent to it (across all brokers).
If the consumer subscribes to the topic on one of the brokers, it will only get the subset of the messages that the broker receives, correct?
I guess I could create a consumer for each broker and aggregate the messages together, but then I'm also on the hook for dealing with connection issues and needing to know which brokers are available, etc.
Question, is there a way to configure the network of brokers or consumer to get all the messages from a distributed JMS topic?
If the consumer subscribes to the
topic on one of the brokers, it will
only get the subset of the messages
that the broker receives, correct?
Technically, yes, but the broker network is responsible for knowing which consumers are interested in which messages, and making sure that the right brokers get the right messages.
Normally, this means that every broker gets every message, but if a broker only has consumers with a given message selector, it will only get messages that those clients are interested in.
In practise, this means you pick a broker, connect to it, and let the broker network sort it out amongst themselves. In theory.
You just connect to the cluster. It is up to the cluster to deliver the messages to the consumer.