Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-6554

[7.8.x clone] Setting of an OpenWire message ID from Core ID causes to javax.jms.JMSException: Suppressing duplicate delivery on connection.

XMLWordPrintable

    • False
    • False
    • ARTEMIS-3776
    • Workaround Exists
    • Hide

      Only for JMS clients (is not possible for e.g. .NET clients):
      If the OpenWire consumer connection URL can be configured, it should be possible to workaround with a URL configuration parameter:
      <brokerURI><?&>jms.checkForDuplicates=false

      Show
      Only for JMS clients (is not possible for e.g. .NET clients): If the OpenWire consumer connection URL can be configured, it should be possible to workaround with a URL configuration parameter: <brokerURI><?&>jms.checkForDuplicates=false

      Two brokers are in a symmetric cluster (Node 1 and Node 2). IN queues and OUT queues are on both brokers. OpenWire producers and consumers are connecting to both brokers. Producers send to OUT queue, consumers receive from IN queue. Core internal application that delivers messages from OUT queue to IN queue. Previously, when an internal application was using OpenWire, these errors did not happen. But now, the internal application uses Core protocol for routing messages from OUT queue to IN queue and error AMQ222149 javax.jms.JMSException: Suppressing duplicate delivery on connection appears when consumers try to consume messages from Node 1 (but not when they consume messages from Node 2).

      Strangely enough, the AMQ222149 Suppressing duplicate delivery on connection appears for messages with message ID higher than MAX INT (2 147 483 647). Also this error appears also on Node 2, but consumers report no issues with delivery.

      Interesting point: This exception appears in broker logs suddenly after several weeks of smooth operation and then there are many of these exceptions and many messages are not delivered. But some messages are still delivered.

      When broker's data folder is deleted, the problem is gone and there are perhaps several weeks of smooth operation until the issue appears again.

              csuconic@redhat.com Clebert Suconic
              rhn-support-zstrmisk Zdenek Strmiska
              Tiago Bueno Tiago Bueno
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: