in the absense of xa, I think we can do better with the redeliveryflag such that it can be used as a reliable indication of duplicate dispatch. In that way, an application can avoid doing duplicate checks when the flag is not set, even after a broker failure.
It will come as a cost, but it opens up a new class of usecases. see: https://issues.apache.org/jira/browse/AMQ-5068 On 25 February 2014 02:54, David Jencks <david_jen...@yahoo.com> wrote: > 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 <fancye...@gmail.com> 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 <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. > -- http://redhat.com http://blog.garytully.com
