Hello,
I too have complained of the missing NAK feature in these various forums - it comes up every few months now I would say.
In client ack mode, if you don't ack, then the message is retained on the server in some limbo, but not sent again (yet).
Once the connection is lost to the client that received the message, but did not ACK, the message is returned to the queue, and will then be sent again to a different connection/subscription.
Some have suggested before to use disconnect/reconnect/resubscribe as a poor man's NAK - as this has the effect of returning the un-ack'd message back to use. This does have the downside that the same message could keep getting resent again and again, although perhaps the message timeout settings in activemq would help. It has has the downside that unless you are using durable topics, it can result in missing messages.
Stomp transactions do no not help either, as you correctly point out, they only work with sending, not receiving, messages.
I wrote a workaround (that not everyone likes) for use in ActiveMessaging.
Rather than use the hack of severing the connection to simulate a NAK, I wrote my own logic to create a clone of the message (retaining a count of how many times it has been cloned, original message id and send time, etc. in custom headers), and then in a transaction ack the original message and put this cloned message on the queue. So in effect, it is like returning the original message, except because it is a clone, it loses its place in the queue, and some meta data like message id will differ.
Not a perfect solution, but I like it better than killing the connection and resubscribing for the reasons above, though I'll probably end up implementing that option too (there was a user offering to do it and send me a patch, but I don't think that ended up happening).
-Andrew Kuklewicz
Vadim Zaliva wrote:
Hi!
I am trying to use ActiveMQ and Stomp protocol to implement scenario
where are multiple consumers are processing messages from single
queue. I want to make sure that only one consumer will get the
message, and he must acknowledge it, so the message will get back to
queue if it has not acknowledged for some time.
One of problems I see is that there is no NAK command in stomp. So,
once I have received the message I could not send NAK to reject it
back to the queue, so it will be delivered to another consumer.
Another problem, or rather a question, is what happens to not ACK-ed
messages. Are they delivered to other consumers and under what
conditions?
Perhaps I can use stomp transactions, but I am not sure how they apply
to receiving messages.
Sincerely,
Vadim
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email