JBossDeveloper

I don't have time to spend setting this all up.  As noted previously, a reproducible test-case is something I can run to reproduce the problem (i.e. not something I have to spend time setting up).  I recommend you simply take one of the examples shipped with HornetQ, modify it to reproduce the problem you're seeing, and then attach that to your comment.  The examples are simple and self-contained.  I can then take that and extract it to the examples directory and reproduce the problem by running one command.

One more thing...Don't create new documents and attach the files there.  Just attach them directly to your comment using the "advanced editor."  You can use the "advanced editor" by clicking the link "Use advanced editor" near the top right of the comment box.

I had a bit of time to set this up so I gave it a shot.  Here are my observations:

1. The configuration you attached wouldn't even start.  I had to first correct the *-directory elements in hornetq-configuration.xml and then remove the duplicate JNDI entries in hornetq-jms.xml.
2. Your problem is related to your queue/address configuration.  Basically you have multiple queues associated with each address so you get what looks to be duplicate messages when, in fact, that is exactly how the broker should behave under this configuration.  To be specific, you were sending messages to the address "jms.queue.QueueA" and this address had 2 queues associated with it - "QueueA" and "jms.queue.QueueA".  The bridge was configured to move messages from "QueueA" to the address "jms.queue.QueueB".  However, the address "jms.queue.QueueB" also has 2 queues associated with it - "QueueB" and "jms.queue.QueueB".  Here is what you should be using for your use-case:

  <bridges>
    <bridge name="Queue-A-B-bridge">
          <queue-name>jms.queue.QueueA</queue-name>
          <forwarding-address>jms.queue.QueueB</forwarding-address>
          <retry-interval>1000</retry-interval>
          <retry-interval-multiplier>1.0</retry-interval-multiplier>
          <reconnect-attempts>-1</reconnect-attempts>
          <failover-on-server-shutdown>false</failover-on-server-shutdown>
          <use-duplicate-detection>false</use-duplicate-detection>
          <confirmation-window-size>10000000</confirmation-window-size>
          <static-connectors>
            <connector-ref>in-vm</connector-ref>
          </static-connectors>         
    </bridge>
  </bridges>

  <queues>
    <queue name="jms.queue.QueueA">
      <address>jms.queue.QueueA</address>
    </queue>
    <queue name="jms.queue.QueueB">
      <address>jms.queue.QueueB</address>
    </queue>
  </queues>

Again, I encourage you to read the JMS-to-core mapping documentation that I linked previously.  It should help you avoid errors like this in the future.

The only technical reason you need to define destinations in hornetq-jms.xml is if your JMS clients needed to look up the destinations via JNDI.

No "trials" should be necessary.  You simply should read the documentation I linked previously.  It explains the JMS-to-core mapping.  I think all your issues could have been avoided from this simple step.