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 <a...@artnaseef.com> 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.
