The use-case sounds like one that needs more than just ActiveMQ to solve well.
In JMS, redeliveries of messages must be expected and handled by applications. There are cases where the JMS redelivered property is set, but the application may not have touched the message ever before - such as when the message is dispatched in the prefetch for the client and the client terminates without getting to the message. Even with prefetch 0, the same problem can happen. The JMS redelivered property is a hint that lets an application know that there is a risk the message was actually handled before. My preference is to think of JMS guarantees as a great way to simplify the normal processing path in an application as it eliminates the need to consider how messages can get lost in transit and protecting against the same. However, it's not intended to be a way to signal to the broker to try a different consumer. And it doesn't eliminate considerations under error cases - such as a consumer terminating in the middle of processing the message. On the practical front, rejecting a message so that the broker resends it will introduce notable delay. It may also result in the message being redelivered to the same client. Also, I would need to check -- there may also be a TTL issue in which case the message could end up stuck on the broker. In your use-case, I would consider ActiveMQ as an underlying component to a complete solution. Perhaps using camel with a server that routes tasks to task engines. Also, I recommend considering a proactive approach to the problem. Waiting until the task reaches a task engine to have it rejected may lead to problems. For example, what if the fastest task engine is too slow for the task? The task will starve. Using feedback from the task engines to the routing engine, the routing engine can decide the best task engine using heuristics (such as best fit - not always the fastest engine). To get the guarantee a task only ever executes once, you'll need a reliable lock/state engine. Zookeeper comes to mind. Note that many applications prefer to use an idempotent processing model so that duplicate processing causes no problems. Hope this helps. -- View this message in context: http://activemq.2283324.n4.nabble.com/does-AUTO-ACKNOWLEDGE-guarantee-once-and-only-once-semantic-for-queue-consumer-tp4678300p4678338.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
