Asynchronous [JMS] [ActiveMq] How the retry mechanism does not cause a message to be executed multiple times.

The problems and solutions of the single machine affairs of Taobao's mass storage
http://blog.csdn.net/jiao_fuyou/article/details/15499261
This article is quite good. Core keywords: idempotent.

Message Queue Activemq:redeliver, how to do the retry mechanism does not result in a piece of information being executed multiple times. Http://stackoverflow.com/questions/4934386/avoiding-duplicated-messages-on-jms-activemq this inside mentioned two. One is a camel component that can be integrated into MQ. idempotent Consumer ( Idempotent Receiver http://camel.apache.org/idempotent-consumer.html contains a concept idempotent Receiver roughly looked down and had JPA.  To be honest, I didn't see how to do it, the mail group also asked, see the attachment below, one is the business-side implementation (Official document recommended http://activemq.apache.org/should-i-use-xa.html). The other is a XA/JPA distributed transaction. (http://activemq.apache.org/should-i-use-xa.html)
A: Keyword ① message is not lost, ② message is not repeated execution is a problem of two aspects.                Can not be a failure. 1. Programme. Add a table to the business end to store, the message is executed.  After each business transaction commits, the server side is told to have processed the message.               Even if the server receives a timeout, it causes multiple business machines to receive messages. Nor will it result in duplication of processing. Think of a point that does not need to be specifically judged to be a unique sqlException or other exception. This can be directly as a chance exception. Let MQ retry.   The next time you try to run into a business logic check checkmessageexist (), and then discard this message, no longer try again. This scheme does the ① message is not lost, ② message does not repeat the dependent message repeatedly sent. Messages are not lost and messages are not repeated. jpg
2, a way of thinking. Let the server record. When acknowledge is returned, the decision is made whether it has been performed, and if not, the number of executions is +1, informing the user of the commit transaction.             If it is, inform the client that the transaction is rolled back. This scenario flaw, such as acknowledge acceptance success, but the business end transaction commit failure (power failure, hard drive error), causes the message to be lost. This scheme only achieves the ② message does not repeat executes, does not do ① the message not to lose. In some cases it is possible that the message is lost.


The second scenario deals with the problem of occasional failures. The database hard drive is broken, the power outage has not persisted successfully. And the persistence succeeded the hard drive broke down there's a difference the former data is lost, completely unable to recover, the latter also have the probability will be lost, but the OP will pass the mechanism as far as possible without loss, if really lost. That's not something that people can control. For example, no off-site disaster recovery, such as the destruction of the Earth        .        For the former our business side through the "programmatic automatic retry" or "Synchronous return error for users to upload" can avoid the former message/data loss. Programmatic automatic retry is more important to the asynchronous framework, and the ACTIVEMQ is to avoid the loss of messages by retrying.
The latter's data cannot be recovered and not controlled by business-side programming. The OP needs to be guaranteed as much as possible through certain mechanisms.


Pasted from: The background here ... http://activemq.apache.org/should-i-use-xa.html   typically you either need to implement Your own duplicate message detector use an idempotent consumer ... Power and other consumers.   Core critical http://activemq.apache.org/camel/idempotent-consumer.html or use XA.   Another Approach method I ' ve used with customers are that for JPA stuff that might fail (because JPA may fail), use a JPA endpoint In Camel as part of your JMS send (so it really just does a JPA insert under the covers using your Jpatemplate object and Using the same transaction), then in the ActiveMQ Broker bridge out of your to a queue.   e.g. in your code send to destination   new Cameldestination ("jpa:com.acme.MyEntity");   Then in your activemq.xml have a rule ...   <route>   <from "jpa:com.acme.MyEntity"/>   & Lt;to "Activemq:myqueue"/> </route>   This then means rather has the XA than; You can stick to simple JDBC operations and transactions; ThEn get the broker to poll the "database and bridge it to" a message queue in a separate transaction (which typically'll ha ve less risk of creating duplicates).   If you are not using XA for really should have some kinda duplicate detection in there into case just.     on 05/11/2007, DMD <dmd17@cornell.edu> wrote: > > Hi All, > > I am Using JPA (currently WI Th OpenJPA) to persist the execution state of a > process.  I sometimes need to use the same transaction to Consum e a message, > update the "State of the" process and persist it to disk, and generate some > message. > > essentially I have two services which communicate via JMS and both need to > recover from failures and not lo Se their state or messages in transit. > > Now, I can ' t yet figure out how to configure the system in order to share > the transactional context...&nbsp ; Furthermore, I don ' t know if that's requires > that both the ActiveMQ broker and the JPA mUST use the same db.  (obviously > there is a requirement this DB itself be highly available.  We are USI ng > MS SQL Server with a shared storage configuration.) > > Any help would is appreciated, including someone telling me that I ' m on > totally the wrong track and I Shoul D use some the other technologies. > > Cheers, > Dan > >--> View this message in Context:http://www.nabble.com/activemq-and-jpa-with-glo bal-transactions-tf4752732s2354.html#a13590338 > Sent from the Activemq-user mailing list archive at nabble.com. > >