Using activemq with a jta transaction manager and using the appropriate xa interfaces (such as through the resource adapter) will guarantee that a message is delivered exactly once. Many people prefer to use idempotent messages to avoid the xa overhead.
david jencks On Feb 24, 2014, at 6:45 PM, Li Li <[email protected]> wrote: > thanks. Since JMS can't guarantee only once, it's the client's > responsibility to make things correct. it should either using > idempotent processing(running a task twice is no harm) or using other > tools(such as zookeeper or database to make data consistent). So I > think there is still many dirty work to do in some strict environment. > is there any practical usage of JMS(activemq) in real world in > industry such as financial or e-commerce? > on the other hand, does JMS guarantee at least once delivery? What's > the redelevery mean? > as said in > https://activemq.apache.org/message-redelivery-and-dlq-handling.html > > Messages are redelivered to a client when any of the following occurs: > > A transacted session is used and rollback() is called. > A transacted session is closed before commit is called. > A session is using CLIENT_ACKNOWLEDGE and Session.recover() is called. > > I notice that when a client crashed in the onMessage method and > restart. the message will be dispatched to another consumer with > getJMSRedelivered()==true. it this message a redelivered one? > also, if the consumer is very slow(maybe hang for an hour,stay in > onMessage so it's not acknowledged) and the message has a short TTL, > will it be redelivered to another consumer or to dead letter queue? > > > On Tue, Feb 25, 2014 at 10:10 AM, artnaseef <[email protected]> wrote: >> 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.
