The fix in https://issues.apache.org/jira/browse/ARTEMIS-3521 gives you the option to disable the use of duplicate id by the openwire protocol adapter. see example usage in the test: https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=blob;f=tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/openwire/FailoverDuplicateIDUsageTest.java;h=3231256e1a5d037d364844221813ef51392eb02e;hb=15c2dbb#l54
Otherwise, the use of duplicate detection is configurable on an address level via address settings, you could disable it altogether with a wildcard match. On Wed, 16 Feb 2022 at 08:08, Brad Harvey <brad.har...@gbst.com> wrote: > > Hi, > > I'll put my questions up the top so they don't get lost, see background below > for the context. > > Question 1 - I do not want duplicate detection (1) to roll back entire > transactions. Is there a way to change the behaviour so that the entire > transaction does not get rolled back? The behaviour I would like is to > either silently drop the single duplicate message and commit the rest of the > transaction, or not be enabled at all (as the application has duplicate > detection). > > Question 2 - I think consuming a message from artemis using the openwire > protocol sets the _AMQ_DUPL_ID header on the consumed message which is > available to the client to read (2). Is there anything in the activemq > classic openwire or qpid jms amqp libraries that would result in this > property being set under the covers when sending a message? > > > Background: > > I ran into issue where artemis' duplicate detection triggered, causing > transaction rollback. I say unexpected because we don't set the duplicate > detection header explicitly in our code. > > Artemis 2.20.0. Communication is using the Openwire protocol with ActiveMQ > Classic JMS client libraries. > The application is Apache Camel based. There's a route that reads multiple > messages from queue "A", does "stuff", then sends them onto another queue "B" > using a JMS transacted session. > > The problem encountered was a failure in committing the transaction after > writing to queue "B": > > 2022-02-14 12:52:16.898 INFO ||ID-syn-ang-rbau-csp-1a-1644803524964-0-40| > 1593489 --- [n.FromCSPSigned] org.apache.activemq.TransactionContext : commit > failed for transaction TX:ID:hostname-44825-1644803526098-1:1:4 > javax.jms.JMSException: > org.apache.activemq.artemis.api.core.ActiveMQDuplicateIdException: Duplicate > message detected - message will not be routed. Message > information:CoreMessage[ <snip> > _AMQ_DUPL_ID=ID:hostname1-42351-1643245903980-1:132:2746:5:1, <snip> > > This caused a rollback & retry in the camel route (expected) which continued > to fail with the same exception until retries were exceeded and the batch of > messages was moved from queue "A" to the DLQ. > > I believe the way the header got onto the message being sent was: > 1. When sending messages to an openwire consumer that uses the failover > transport, artemis adds the _AMQ_DUPL_ID header to the message. (2) > 2. Camel copies all JMS headers to camel message headers when consuming a JMS > message. > 3. Camel copies all camel messages headers to JMS headers when sending a JMS > message. > > And so #3 dutifully set the _AMQ_DUPL_ID header. I think the solution is for > our camel application to use header filters on the camel components so that > #2/#3 does not occur. But I'm concerned about other ways this header might > get set - hence question 1 and 2 at the start of the email. > > Thanks for your time and guidance. > Brad Harvey > > (1) > https://activemq.apache.org/components/artemis/documentation/latest/duplicate-detection.html > (2) > https://github.com/apache/activemq-artemis/blob/1e6297957766138c312273cbbd15327c22f91c53/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQSession.java#L397 > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and / or privileged > material that may be governed by confidential information provisions > contained in the agreement between GBST and your company. Any disclosure, > copying, distribution, or other use without the express consent of the sender > is prohibited. If you received this in error, please contact the sender and > delete the material from any computer. All rights in the information > transmitted, including copyright, are reserved. Nothing in this message > should be interpreted as a digital signature that can be used to authenticate > a document. No warranty is given by the sender that any attachments to this > email are free from viruses or other defects.
